This makes checking out the nixpkgs repo even more consistent and almost
forces us to use the trusted/untrusted path pattern.
(cherry picked from commit 0e1c284b13)
By consistently checking out nixpkgs into the same location in every
workflow, it's easier to reason about the different workflows at once.
We also use crystal-clear names to make clear, which checkouts are
considered trusted, because they only contain target-branch-code and
which checkouts are untrusted, because they contain code from the head
branch. By naming the checkout directories trusted/untrusted, it's
obvious at the call-site.
One example of where we likely did the wrong thing is the nixpkgs-vet
workflow: Fetching the toolVersion from the untrusted checkout opens the
door for an injection into the download URL, thus code could be
downloaded from anywhere. This is not a problem, because this workflow
does not run with elevated privileges, but it's a scary oversight
nonetheless.
(cherry picked from commit 6720d25429)
`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)
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)
We intend to use the edited event to react to base branch changes - but
before this change, we also ran those jobs on simple edits like title or
description.
While this works for some of the quicker jobs, it will not be
sustainable for all evaluation-related jobs. But evaluation needs to be
re-triggered on a base branch change as well, thus this change.
(cherry picked from commit 9b01e09a35)
All workflows where it's remotely useful now trigger on a pull_request
event when the workflow file itself is changed. This gives us basic
sanity testing of changes to workflow files itself and reduces the need
for manual tests in forks.
ARM runners are supposed to be more energy efficient than x86. Also,
from limited testing, they appear to be faster for the eval jobs as
well. Average run time for the "Outpaths (x86_64-linux)" job was 4m 27s,
so far. In the first run, this job came in at 3m 9s. This effect did not
show for other jobs, yet.
The following two exceptions are made right now:
- nixpkgs-lib-tests currently fails on the ARM runner building Nix 2.3
- nixpkgs-vet is currently pinned to a x86_64-linux only binary release
This introduces some basic concepts used in these workflows and a common
terminology.
At the same time we remove some of the comments from various workflow
files, because they are assumed to be "general knowledge" through the
README.
Same top-level ordering of keys / empty lines and same indentation for
yaml lists. One blank line between each step.
Makes it easier to read and compare the workflows.
Currently we need to rely on ofborg requesting reviews from package
maintainers, which takes a while with ofborg's eval queue. Since
recently we're doing faster evaluations with GitHub Actions, which contain all
necessary information to determine reviewers of changed packages the
same way ofborg does. This PR takes advantage of that.
After the introduction of the reusable get-merge-commit.yml workflow,
this now applies it on all remaining workflows that depend on a merge
commit. This ensures that CI doesn't fail for those PRs, which would
cause notifications to be sent, and the CI run to be marked as failed in
the list of runs.
In the previous two commits, security issues with these workflows were
fixed. In order for these to not be exploitable for PRs to branches that
don't have the fixes yet (including read-only branches like
nixos-unstable), these workflows are renamed, so that the old ones can
be turned off manually via GitHub interface.
Co-Authored-By: 13x1 <tori@disroot.org>
Co-Authored-By: basti564 <e3e@disroot.org>
