AutoMerge: Allow skipping sequential versions with author-approval criteria

[ericphanson]

Based on #536 to avoid conflicts. That one should be merged first.

Requires https://github.com/JuliaRegistries/General/pull/98815

The flow here is:

• automerge comments, notes they can override
• package author comments "[merge approved]"
• GHA adds a label
• new label triggers automerge again
• automerge sees the new label and skips the sequential version check

FAQ:

• What happens if some one else comments "merge approved"? The label doesn't get applied, so nothing happens
• What happens if someone adds the label manually? The label does take effect. I.e. triage-level maintainers can facilitate author approval if needed. We need to trust them to not abuse this (I doubt it will happen and we can revoke triage access if folks aren't behaving)
• Does a "merge approved" comment block automerge unless it contains [noblock]? No, we special case it so comments that trigger author-approval count as noblock.
• Does AutoMerge's comment mentioning "merge approved" trigger the labelling workflow? No, it shouldn't, it is a bot user. (If it did, the label would still not be applied, since the registrator is not the package author)
• What happens if multiple guidelines use the author-approval mechanism, does the author have to indicate what they are approving? No, merge approved will apply to all of them
• What happens if the author comments before even seeing the automerge comment? They would end up approving whatever it says, but only 1 guideline is overridable at this point.
• What happens if the PR is from gitlab? We won't be able to find the author's github username in the PR text from Registrator, so the labeling workflow won't be able to check the commenter is the author, so the label won't get added. Triage-level maintainers can manually add the label in this case, but there isn't an automatic solution.
• What happens if the PR is not from Registrator? The label could still get added by the workflow (if it hits the regex to have the author name, and the person with that username comments), but automerge won't run, so the label won't do anything.

[DilumAluthge]

• GHA adds a label
• new label triggers automerge again

This might be a problem. If the label was added using the default GITHUB_TOKEN token, then IIRC the "label-added" event won't trigger any further GitHub Actions.

[DilumAluthge]

• GHA adds a label
• new label triggers automerge again

This might be a problem. If the label was added using the default GITHUB_TOKEN token, then IIRC the "label-added" event won't trigger any further GitHub Actions.

Can we make the "GHA adds a label" step use the custom @JuliaTagBot PAT we have? I believe that this would bypass the above issue.

Of course, maybe we should first verify that the above actually would be an issue.

[DilumAluthge]

Perhaps we should make the text specific to the guideline being approved? How about something like /approve-merge-skip-version?

Also, how about we add the / to the front, to emphasize that this is kind of a "command" that the package author is providing?

We've settled on [merge approved]

[DilumAluthge]

Even if we only get this working for GitHub-hosted packages at first, this still covers the majority of packages, so I still think it'll help reduce the manual registry-committer burden.

[ericphanson]

This might be a problem. If the label was added using the default GITHUB_TOKEN token, then IIRC the "label-added" event won't trigger any further GitHub Actions.

Good point, I think that sounds right.

Can we make the "GHA adds a label" step use the custom @JuliaTagBot PAT we have? I believe that this would bypass the above issue. Of course, maybe we should first verify that the above actually would be an issue.

Yeah, that makes sense. Since this can be done on the GHA by itself, IMO we can work on that once we merge down the stuff here and get RegistryCI updated on General. Then we can try it out and get the authentication working there.

Perhaps we should make the text specific to the guideline being approved? How about something like /approve-merge-skip-version? Also, how about we add the / to the front, to emphasize that this is kind of a "command" that the package author is providing?

To me this seems overly complicated. Since RegistryCI prints all of the problems it found at once, the author can either approve merging or not knowing that information. I don't really feel like there's more than 1 decision the author actually has, since not approving 1 thing blocks merging (so ultimately they need to decide if they want to merge now or not).

I also think this will lead to more questions/issues where folks approve 1 thing but not another and are confused.

I think "merge approved" is straightforward and simpler.

Even if we only get this working for GitHub-hosted packages at first, this still covers the majority of packages, so I still think it'll help reduce the manual registry-committer burden.

Agreed!

[ericphanson]

Re- the token, the docs here seem clear that indeed GITHUB_TOKEN is insufficient for this, and we should use a PAT. We could use an existing one or make a new one for the task.

[DilumAluthge]

We could use an existing one or make a new one for the task.

For now, probably easier to re-use the existing one (the @JuliaTagBot token that AutoMerge uses when merging a PR). But we might consider making a new one in the future.

[DilumAluthge]

@ericphanson This needs a rebase, I think.

[ericphanson]

(updated)