workflows: publish approved PRs upon CI completion

[carlocab]

This is based on one of @MikeMcQuaid's suggestions on Slack.

We add an automerge.yml workflow that is triggered by the
workflow_run event. We need this in order to escalate access of
GITHUB_TOKEN from the pull_request and pull_request_review events,
which can only have read access to the GitHub API.

The automerge workflow is triggered by two events:

• completion of a CI workflow on a pull request
• approval of a pull request

Because both of these events are required in order to merge, we allow
the workflow to wait for a while to check if the other event occurs.

The basic idea of this workflow was borrowed from the documentation on
workflow_run events.

[carlocab]

I've tested modified versions of these workflows in a separate repository, and it seems like it should work, barring issues with concurrency and GITHUB_TOKEN permissions.

There's also the question of all the boilerplate.

[MikeMcQuaid]

Think I'm fine with this but not sure I totally understand

• what it's doing
• why it's needed
• how it differs from the existing auto-merge logic in PRs
• how it differs from/complements/replaces the existing "brewtestbot pushes to PR" flow(s)

Happy to answer these questions post-merge but would love to understand better. Thanks again @carlocab!

[carlocab]

This might help refresh your memory: https://machomebrew.slack.com/archives/C06G173B7/p1680113506757109

The idea is that we want a workflow triggered by pull_request_review to run brew pr-publish (or otherwise somehow merge the PR when CI is done). The problem with doing that is that pull_request_review workflows have no access to secrets, and have a read-only GITHUB_TOKEN.

The solution to that is described in the docs for workflow_run events:

The workflow started by the workflow_run event is able to access secrets and write tokens, even if the previous workflow was not. This is useful in cases where the previous workflow is intentionally not privileged, but you need to take a privileged action in a later workflow.

So at minimum, what we need is for a pull_request_review workflow to trigger a workflow_run workflow that can do brew pr-publish. Here, the workflow_run workflow is automerge.yml. Since it's triggered by successful completion of a pull_request_review workflow (reviews.yml), we may as well also trigger it on successful completion of tests.yml on a pull_request event. The rest is mopping up details.

The difference with the existing autopublish.yml workflow is that autopublish.yml runs on a timer, while in theory this should allow for merging PRs sooner than that.

This is mostly independent of the "brewtestbot pushes to PR" flow, I think. We could do this even if we didn't push to PRs, and it doesn't really improve upon or detract from that flow in any way (AFAICT).

[MikeMcQuaid]

The difference with the existing autopublish.yml workflow is that autopublish.yml runs on a timer, while in theory this should allow for merging PRs sooner than that.
This is mostly independent of the "brewtestbot pushes to PR" flow, I think. We could do this even if we didn't push to PRs, and it doesn't really improve upon or detract from that flow in any way (AFAICT).

Perfect, all good to me to merge then, thanks @carlocab!

[ZhongRuoyu]

I'm thinking if this will result in duplicate bottle publish workflow runs if an approval happens to be on the hour (i.e., coincides with the hourly workflow).

Maybe we could add a concurrency to the publish-commit-bottles workflow?

[MikeMcQuaid]

@ZhongRuoyu Good point.

Maybe we could add a concurrency to the publish-commit-bottles workflow?

They should probably share the same concurrency key.

[carlocab]

Yes, this is one of the concurrency issues I said I was still not sure about. Will think about how to handle this better.

[carlocab]

Pushed my branch to this repo for better testing. #128697