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.
