In 1d03944a9c failures from pushing notes were ignored entirely due to
the command failing sporadically. Looking at the original commit message
this was almost certainly due to the fact that multiple runs of the
workflow could happend simulaneously if PRs were merged in quick
succession:
1. PR 1 gets merged.
2. Workflow run 1 gets triggered for newly pushed `master` commit from
PR 1 and fetches notes ref at `aaaaaaa`.
3. PR 2 gets merged.
4. Workflow run 2 gets triggered for newly pushed `master` commit from
PR 2 and fetches notes ref at `aaaaaaa` as well.
5. Workflow run 1 finishes its work and pushes `bbbbbbb` to the notes
ref.
6. Workflow run 2 finishes as well, tries to push `ccccccc` to the notes
ref, but gets rejected. This is because its changes are based on
`aaaaaaa` and cannot be fast-forwarded due to workflow run 1 having
pushed different notes in the meantime.
This sequence of events could also be observed after bbad346add got
merged, which caused the first couple workflow runs after to be very
slow as they were processing a large backlog of missing notes.
Instead of silencing the error when it happens and relying on the fact
that the next run will correct it, let's just prevent the conflict from
happening in the first place by disallowing parallel runs of the
workflow. This avoids unnecessary workflow runs and allows detection of
other, unexpected errors happening when pushing.
bbad346add corrected a URL that broke several weeks ago. This problem
went unnoticed for a while partially because the workflow runs were all
still passing. A failure of a command in an &&-list is only considered
an error if it occurred in the last command of the list, even with `set
-e` being active (set automatically in GitHub actions).
From the Bash Reference Manual, 4.3.1 The Set Builtin:
> The shell does not exit if the command that fails is [...] part of any
> command executed in a && or || list except the command following the
> final && or ||.
Let's make download failures easier to disover by failing the workflow.
Every master-push getting marked with a red x-sign would probably have
been caught earlier.
The notes-push.yml script was silently failing since the previous URL
now 404s, causing notes to remain unupdated since January 18. This new
URL should work for as long as the git-gloss repository exists.
The people over at Blacksmith.sh have generously offered usage of their
runners for our organization, so let's try to switch over some simple
workflows. The runners should be drop-in replacements.
It’s possible but unlikely that a push of generated notes back to the
remote can fail with a message like
> [remote rejected] ... cannot > lock ref 'refs/notes/commits': is at
> f3648f50bb but expected 47686bf473
See https://github.com/LadybirdBrowser/ladybird/actions/runs/10054314539
So this change makes the call to “git push” for notes not return 0 even
if it fails — because it’s not actually a fatal error when it happens,
and not something we need to stop and fix. Instead, it fixes itself.
Specifically: If one CI job for a PR merge/push to master generates
some notes but fails to push them to the origin, the notes don’t get
dropped on the floor and lost.
Instead, the notes-generator tool looks at the entire history; and if it
finds commits that don’t have notes — even if those commits are not part
of the PR push/merge it’s operating on — it generates notes for those.
In other words, if notes for one PR push/job fail for some reason to get
pushed back to the remote, they get regenerated by the next PR push/job.
This change makes the notes-push.yml·workflow fetch the entire history
on each push, rather than just the one HEAD commit it otherwise sees.
Because we push multiple commits from PR merges, git-gloss need access
on each push to an arbitrary number of commits (however many commits
were pushed in a PR that got merged). There’s no easy way from GH
Actions to know how may commits got pushed at the same time. So we
instead fetch the whole history.
This change, for each commit pushed/merged to master:
- causes new git Notes with GitHub PR/issue/reviewer/author links to be
auto-generated for that commit
- pushes the updated refs/notes/commits tree+references back to the repo
