LGTM

Pardon my ignorance: why does this default to dist-git-gating-policy-{}-{}, in case there is no policy.id? I would expect something like None.

Also, what should happen in line #17, when there is no policy.id ?

@csomh If there is no id in policy, just after it's loaded from gating.yml, it'll be set todist-git-gating-policy-untitled-<PACKAGE_NAME>.

Later in the code it should be already set to the new descriptive value for better error handling and serialization.

Ah, ok, so this is fixing issue #217 ... it makes sense now, why this default id was chosen.

:+1:

Commit 0640b2c2 fixes this pull-request

This is part of #217, right?

In future can you please put a phrase like "Fixes #217" into either the commit message or PR description or both. It helps to cross-reference which issues are fixed by which PRs. And it helps to give more context if you are readying a git log and want to understand why a change was made.

@dcallagh I usually do that but I don't add "Fixes #..." to commit if they shouldn't close the issue. In this case there are multiple commits needed for the issue to be fixed (and I'll probably create another PR for this soon).

Also, just yesterday, I needed to enable a git hook in Pagure (for waiverdb and greenwave) for the phrase "Fixes #..." to have an effect because I noticed there were lots of open issues with merged PR containing the phrase.

I don't know if just mentioning the issue ID anywhere in commit message will create a link on some other phrase is needed (without closing the issue).

Oh yeah, I wasn't talking about any kind of automated issue closure (didn't even know Pagure could do that already). But it is nice to be able to follow the trail from a git commit or PR back to the corresponding issue.

If we are using "Fixes #..." to trigger automatic closure, but your commit does not fully fix an issue, you can just write like "Related to #..." or "This is part of the fix for #..." so that we still have a textual reference between them but the automation won't pick it up.