add `AutoMerge: last run blocked by comment` and `Override AutoMerge: ignore blocking comments` labels

[ericphanson]

This is the first RegistryCI feature that involves adding/removing labels programatically, as opposed to previous work that only reads them. This only affects the cron job. When it runs, it

1. Checks if the label "AutoMerge: last run blocked by comment" exists. If not it creates it. This will require new permissions, so this change is likely breaking
2. For each PR, if the PR has the label "Override AutoMerge: ignore blocking comments" then the PR does not count as blocked
3. if a PR is blocked, the label "Override AutoMerge: ignore blocking comments" is added (again, this needs new permissions)
4. if a PR is not blocked, the label "Override AutoMerge: ignore blocking comments" is removed (again, permissions)

Specifically, the permissions needed are: the github token by the cron job needs at least one of:

• "Issues" repository permissions (write)
• "Pull requests" repository permissions (write)

[DilumAluthge]

Unit tests on Julia 1.3 should be fixed now after https://github.com/JuliaRegistries/General/pull/112623. I'll retry that job.

[ericphanson]

Is there a way to try the integration tests without merging?

[DilumAluthge]

We could add a workflow_dispatch trigger to the integration tests, which would allow us to trigger them manually.

[DilumAluthge]

All of this work is done in the cron job, right? This doesn't change anything in the PR job?

I haven't done a line-by-line review of the code, but at a high level, I understand the motivation here:

1. Increase the visibility (to the PR author) when a PR is blocked by blocking comments.
2. Give registry triagers the ability to override blocking comments.

[ericphanson]

Yep, exactly. The “blocked” label is intended to be managed entirely by the cron job to communicate status, and is set and removed by it. If a human adds or removes it, it will just be corrected next cron run to surface the actual status.

The override label is never set or removed by the cron job, only read. It allows ignoring blocking comments; it’s easier than editing “noblock” into every comment, and it allows triage members to overrule community blocks if necessary.

I hope these have the following effects:

• package authors can understand more easily when their PR is blocked (maybe even by their own comments)
• One can tell without even clicking into a PR which ones are blocked, or filter PRs by blocked/unblocked ones for an easier overview
• Triage members have a new tool for moderation/maintence that makes things slightly easier.

[DilumAluthge]

Those details sound good to me.

[ericphanson]

ok, think this is ready to go. I believe it is non-breaking, since while it needs write permissions for the PR, it is part of the cron job which needs merging permissions anyway. It does not add or remove labels in read_only mode.