Retry transient GitHub API failures when resolving ci/pinned.json so unrelated PR jobs can continue.
Assisted-by: pi coding agent / Mika (OpenAI gpt-5.6-sol)
We run out of disk on the latest pinned version on MacOS only, because by
default this allocates 50% of memory for the tmpfs, which is 3.5GB on MacOS
(and 4GB on Linux).
We can't increase to 4GB, though, because we get the error
"Desired memsize 4294967296 too large - defaulting to 3758096384 bytes"
if we do.
The logging I add would have saved me a lot of trouble figuring this out.
In a shallow clone, `git fetch` may fail to apply thin packs due to
missing base objects.
We typically don't notice this with first-parent commits and prospective
merge commits, but it seems fairly common with arbitrary PR-branch
commits.
In this instance we don't need the full commit data, we only need to
apply its diff as a patch. So fetch the diff from GitHub's API and apply
using `git apply`.
This partially reverts commit 4787f35ede
With the latest performance improvements, this only adds up to 1s, but
reduces complexity in managing pinned checkouts explicitly, especially
when we need *both* pinned checkouts in the next commit.
Instead of fetching up to 3 times on each new checkout, we now fetch all
the commits we're going to need at once. Afterwards, we checkout the
different worktrees in parallel, which doesn't give us much, yet,
because it would still be IO-bound on its own. Inconsistent IO
performance on disk is also the biggest limitation for checkout right
now, where checkout times range everywhere from 20s to 40s.
By checking out the worktrees on a tmpfs, the actual checkout only takes
1s and benefits from parallelization. The overall checkout time is now
8-11s, depending on the number of commits.
That's a reduction of 10-30s and we get this speedup for almost every
job in the PR workflow, which is huge.
This potentially has a nice side-effect for Eval, too: Because the repo
is in RAM, Eval seems to run slightly faster, up to 10 seconds less.
The two as-at inputs, were not boolean anymore, but GHA didn't complain.
Input types are actually not a thing for composite actions - they are
only documented for callable workflows.
This moves the logic to "check whether the PR can be merged and
determine the relevant commits" into the PR / prepare job directly -
since that's the only place where it is supposed to be used.
Because of the if condition in get-merge-commit, this logic was run
multiple times, for example in the lint workflow, where only one of
targetSha or mergedSha was provided as input. However, this input was
thrown away directly. This might not be a big problem, because this was
not expensive, so far. But with the next commit, this will become more
so.
This also separates the logic a bit cleaner - `prepare` figures out all
the parameters for the whole PR workflow, while `checkout` handles the
consistency around these checkouts.
This just moves the code over to ci/github-script to make it easy to
test and iterate on locally.
The name `prepare` is chosen, because the script will be extended with
the other steps from "PR / prepare" next.
This is slightly faster than downloading and extracting a tarball and
additionally allows a sparse checkout. No need to download docs or nixos
for our purpose.
The data is quite noisy, but suggests improvements from anywhere between
5-15 seconds for each job using the pinned nixpkgs.
This fixes a problem where each workflow would get their own merge
commit. This happens frequently when the target branch is merged into a
the same time, different workflows in the same run will run
get-merge-commit at different times and thus have different merge
commits.
Since the jobs don't really depend on each other, this doesn't cause
practical problems, yet. But it has already led to strange CI failures
in a still unmerged PR, which can be prevented from happening with this
clean approach.
And yes, this saves a few API calls on every run.
Most workflow files are already well formatted, but to make it easier to
keep it that way, we can add yamlfmt.
I personally have a preference for non-indented arrays for YAML, but
wanted to avoid bigger diffs here - the status-quo clearly are indented
arrays.
Some changes are made manually to the get-merge-commit action and the
issue templates. Those would otherwise make yamlfmt misbehave on those.
Using core.setOutput is much nicer than having to parse the json
"result" on the outside. This also avoids some very odd errors, when the
result can, for unknown reasons, *not* be parsed as JSON later on.
Also avoiding a bit of duplication between the "if mergeable" branches.
We don't need a separate workflow anymore, because we don't need to skip
dependent jobs on failures anymore. The biggest failure mode was
"conflict" previously, but we resolved that on the last commit. The
remaining failure modes are so rare, that it's OK to just fail the jobs
in this case instead of marking them as "skipped". Especially, because
the resolve-merge-commit job would have previously failed anyway.
By moving this to an action we avoid running separate jobs each time we
need the merge commit. This also makes the check list in PRs much
cleaner.
