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.
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.
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`.
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.
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.
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.
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.
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.
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.
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.
