search

git-for-windows / git-for-windows-automation

A few GitHub workflows and support code to help with Git for Windows' day-to-day tasks
10 stars 9 forks source link

github-release: in addition to the tag, also push `main` #73

Closed dscho closed 4 months ago

dscho commented 4 months ago

The idea is always to update the main branch after the Git for Windows release is done, to close the PR.

So far, this is done manually. But it's better to automate this. Because then I cannot make mistakes like merging via the Merge button (as I had done for v2.44.0-rc1, which complicated subsequent rebases) instead of pushing to main.

The downside would be that the PR would be closed before the release workflow run had a chance to finish, and therefore any failures may be harder to spot.

dscho commented 4 months ago

The downside would be that the PR would be closed before the release workflow run had a chance to finish, and therefore any failures may be harder to spot.

I guess a much better idea is to do this in the GitForWindowsHelper GitHub App, listening for a successful release Check Run on the respective git-for-windows/git PR, much like it listens for successful tag-git runs.

The only slightly tricky bit is that there are actually several Check Runs, not just a single one:

All of these would need to be checked via the REST API which requires a bit of pagination (e.g. https://api.github.com/repos/git-for-windows/git/commits/0db3af6cead6855bb0d72b7149f5c2d9adb5f835/check-runs?per_page=100&page=2).

An alternative would be to access the git-for-windows-automation workflow run (via the link in the output summary) and look at the jobs (see e.g. https://api.github.com/repos/git-for-windows/git-for-windows-automation/actions/runs/7978659901/jobs). The problem is that those might not have finished yet.

A better alternative, now that I think of it, would be to listen for the completed workflow run in the git-for-windows-automation repository. There, we simply have the conclusion that it was a success, because all the jobs run (and are not skipped, it's just some mirrored Check Runs that are marked as skipped for -rc versions). The trick would be to get from that workflow run to the corresponding git-for-windows/git PR because there is no information in the Get a Check Run response to get back to the git-for-windows/git PR or tag or commit (example: https://api.github.com/repos/git-for-windows/git-for-windows-automation/actions/runs/7978659901). Sadly, searching for a PR comment containing the workflow run ID won't work because the REST API search endpoint searches the rendered text, not the Markdown. But we can search for an open PR with the comment and then follow the comments_url (e.g. https://api.github.com/repos/git-for-windows/git/issues/4828/comments) that does have that link and has author_association == 'MEMBER' (so that we don't fall for jokers who open bogus PRs and add a comment of the exact correct format to throw the automation).

The GitForWindowsHelper GitHub App would need to use the repos/.../git/refs/main endpoint endpoint (with force=false, to avoid accidental force-pushing).