As one of the resident Nixpkgs licensing pedants and reviewer of
several recent changes to this file I think it makes sense to make
the de facto the de jure.
(cherry picked from commit 856cb3108a)
Instead of parsing a plain text file with jq, we can make nix-env output
JSON directly, which is significantly faster.
This saves about 8 out of 10 seconds for the combine step.
(cherry picked from commit 138393e0ba)
compare/maintainers.nix needs to access the current checkout to check
attrpaths, but makes the mistake of using lib from that checkout as
well. All other code in ci/ uses the pinned nixpkgs instance, so
maintainers.nix should do so as well.
(cherry picked from commit d87d760dfa)
Previously, `eval.full` organized the results for the supported systems
in a specific layout, i.e. with a folder with one subfolder per system.
Then, `eval.combine` relied on that.
When using `eval.singleSystem` and `eval.combine` directly, the caller
was responsible to recreate the same layout. This is annoying and
error-prone to do, when downloading artifacts from CI to recreate some
steps locally.
With this change, all the artifacts can be downloaded and extracted into
the same folder - because the result from `eval.singleSystem` already
contains the <system-name>/ subfolder.
(cherry picked from commit eccd9564ab)
`env` blocks are a bit like `let` blocks in Nix. They define a few
things, which are then used in the `run` block. The workflows are
considerably easier to read, if those definitions come first, making it
crystal clear where they belong and requiring less visual jumping.
(cherry picked from commit 82396d1f48)
This makes a difference for the case of a merge conflict: In that case,
the magic `.../merge` branch actually points to the *last test merge
commit* that was successful, which might not contain the latest head
commit in any way. Running the tests on that commit is heavily
misleading. By using the get-merge-commit action, we run on the PR's
head commit in this case, which is much better.
(cherry picked from commit 039a954892)
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.
(cherry picked from commit e48d9d6174)
When a PR is having conflicts with the base branch, we used to skip most
jobs depending on the target branch. With this change, we still run
those jobs, but without actually merging the PR temporarily. That means
we compare the head of the PR with the merge-base of the PR's branch and
the target branch - i.e. the point where the PR branched off.
This is not 100% accurate, but that's not important, because after
resolving the merge conflicts, those workflows will run again anyway. It
allows to give early feedback, though, instead of just skipping all the
jobs.
(cherry picked from commit c77cfb9239)
The reason this was a separate shell script was, that this would be
included in multiple workflows separately. But a while ago this had been
changed to a re-usable workflow, so we can just as well inline the
script.
This also allows us to use actions/github-script, which makes for a much
more readable script than the bash script before.
(cherry picked from commit 277f7b998c)
