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.
(cherry picked from commit c18d1e4af8)
This fixes problems on darwin, where the new tmpfs folder would not be
fully empty, but git only creates worktrees on fully empty directories.
(cherry picked from commit fb32eb0f29)
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.
(cherry picked from commit b51e104439)
By definition the tarball changes on every commit, so it makes no sense
to cache it - it will just waste disk space.
(cherry picked from commit ac93865697)
Pushing the source path to cachix is pointless, because the only source
we're using is Nixpkgs - and that will always be available already via
checkout. No need to ever substitute it, so no need to push it either.
(cherry picked from commit 2400bdf0d4)
This allows setting up a custom cachix cache in a contributor's fork.
That's most valuable when working on CI itself, testing and interating
in a fork. It's required when working on cachix related features
directly.
(cherry picked from commit 025424913f)
This avoids downloading results from cachix, when they don't need to be
rebuilt, which just wastes time and resources.
(cherry picked from commit f105ab12f6)
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.
(cherry picked from commit 8a9f0b8a47)
None of our jobs is expected to run for 6 hours, the GitHub limit. These
limits are generous and take into accounts that some jobs need to wait
for others.
If jobs exceed these times, most likely something else is wrong and
needs investigation.
(cherry picked from commit 436d54174d)
This adds a build job for the tarball, which might help uncover eval
issues on attributes not normally touched by Eval, aka those added in
`pkgs/top-level/packages-config.nix`.
(cherry picked from commit bfb20b9fea)
Committers could get the false impression from, e.g., `PR / Build / aarch64-linux` that this workflow builds the packages changed in the current PR. Such a misunderstanding could pair poorly with the "enable auto-merge" button, once that's enabled.
(cherry picked from commit 261bba1fcd)
Some jobs purposefully only run on certain base or head branches. By
centralizing the logic, parts of it can easily be re-used later. Also,
this gives them an explicit name and thus makes them easier to
understand.
(cherry picked from commit 7763be5a80)
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.
(cherry picked from commit 09ddb1a8a0)
Those two workflows bundle all the main jobs in two event-specific
wrapper workflows. This enables us to do two things later on:
- Synchronize the merge commits between most of the jobs run in a PR.
- Create a single "required" job to be targeted by GitHub's "required
status checks to pass" feature.
(cherry picked from commit 959eed1f2a)
This didn't work as intended. When a workflow is run with
`workflow_call`, it will have `github.workflow` set to the *parent*
workflow. So the `caller` input that we passed, resulted in this
concurrency key:
```
Eval-Eval-...
```
But that's bad, because the labels and reviewers workflows will cancel
each other!
What we actually want is this:
- Label and Reviewers workflow should have different groups.
- Reviewers called via Eval and called directly via undraft should have
*different* groups.
We can't use the default condition we use everywhere else, because
`github.workflow` is the same for Label and Reviewers. Thus, we hardcode
the workflow's name as well. This essentially means we have this as a
key:
```
<name-of-running-workflow>-<name-of-triggering-workflow>-<name-of-event>-<name-of-head-branch>
```
This should do what we want.
Since workflows can be made reusable workflows later on, we add those
hardcoded names to *all* concurrency groups. This avoids copy&paste
errors later on.
(cherry picked from commit 6793e238fa)
This can happen when two PRs run at the same time, which come from
different forks, but have the same head branch name.
github.head_ref is suggested by GitHub's docs, but.. that's not really
useful for cases with forks.
(cherry picked from commit 7ba7720b28)
This new workflow builds both manuals, the shell and the lib tests all
in a matrix of four jobs. This allows re-using the shared checkout and
the pinned nixpkgs download and saves time in the most likely cache: No
changes, just download from cache. Each step checks the cancelled
condition, which causes it to run even if the previous steps failed.
This way we get a full picture even if the first step fails immediately.
This could later be optimized to build more in parallel as well, but
we'll first need to clear the conditions on building the manuals on the
master branch only.
This reduces the number of jobs from up to 8 to 4 for this part.
(cherry picked from commit cd82aa54f5)
