The Eval report which tests performance between Nix/Lix versions on
update of `ci/pinned` wrongly returned errors, when only the special
attribute `release-checks` changed. Since this reads in all of Nixpkgs,
it will change with any formatting change that is introduced at the same
time via update of any of `treefmt`'s formatters.
This change runs Lix on the target commit and Nix on the merged commit.
This does two things for us at once:
- We test both Lix and Nix.
- We ensure that both Lix and Nix produce the same output hashes.
If Lix and Nix were to produce different output hashes at some point,
this would show up as rebuilds in every PR.
This was only separate to work around possible delays from the target
branch's eval workflow. With the switch to the merge queue, this delay
is impossible - the relevant target commit will only appear once Eval
has completed in the merge queue, so Eval will be guaranteed to have
finished.
By running attrpaths and outpaths in the same step, we share ~10 seconds
of eval time, traversing through all of Nixpkgs.
Running eval in the merge queue prevents eval failures after merging
multiple PRs with semantic merge conflicts.
It's also the base for allowing more sophisticated checks about rebuild
counts in the merge queue later.
When branches are directly pushed to, such as for periodic merges, this
will not run Eval immediately. However, the next PR will run it as part
of its Eval step and will cache the results. Any further PR will then
benefit from the same caching again.
This also avoids running Eval twice when pushing to staging-next or
haskell-updates, where a PR is open at the same time. Here, the PR's
Eval still runs on the push, of course.
See https://github.com/NixOS/nixpkgs/issues/437208#issuecomment-3288623669
Depends on https://github.com/NixOS/org/pull/172
As documented below, the idea is to essentially group all changes
rebuilding all VM tests with kernel updates and merge them together into
`master` whenever the Linux kernels get updated.
This documents the workflow of updates in the nixpkgs manual. While at
it, I removed the README from the packages because
* it's horribly outdated
* I didn't even know it exists which confirms that its discoverability
was very poor
and added the relevant portions into the nixpkgs manual as well.
This removes the "owners" check from codeowners-validator. With it, all
tokens and permissions can be removed, because these were only needed to
make these requests.
This solves the problem of codeowners-validator not supporting our new
nested team structure for nixpkgs-maintainers. To make the onboarding of
new teams easier, we moved all teams "under" the nixpkgs-maintainers
team. This makes them inherit the right privileges (triage) for Nixpkgs.
However, this inheritance is not recognized by codeowners-validator,
thus it assumes that these teams don't have access to Nixpkgs. This then
fails the owners check immediately.
Removing the owners check also has a few other advantages:
- This check depends on external state: If a user is renamed or a team
removed, the check will fail. This makes it a bad check for required
status checks or merge queues - the check might fail randomly,
independent of the current PR.
- Running this check in a fork will never work, because the respective
users and teams don't have access to the fork's repo.
Both of this required us to set `continue-on-error: true` most of the
time.
The next few commits will make pantheon-wayland the default.
Note that the Pantheon LightDM greeter option is left untouched
right now since it still runs under X11.
When the merge queue fails, the workflow currently does not post a
negative result - and GitHub Actions waits for the status check to time
out, which takes 60 minutes.
This, of course, is a waste of time and resources. By explicitly failing
the status check, we boot the PR out of the merge queue immediately.
Due to how we pass in existing store paths via CLI arguments for the
diff and combine scripts, Nix didn't register a dependency on the store
paths properly. This meant that some of the derivations that were built,
didn't have the right store paths made available in the sandbox -
leading to all kinds of "not found" errors.
We worked around this in CI by resolving the symlinks to the nix store
beforehand. We tried to work around this locally by storing the nix
store path in BASELINE, but this didn't fully work. By explicitly
registering these store paths as dependencies, this should work across
the board - without any magic required by the caller.
We tried, but GitHub's markdown renderer will render these newlines
there, so going back to "real" paragraphs.
Also fixed the emphasis slightly, since "via Issues" is not bold, "via a
Pull Request" is also made not bold for consistency. Puts the focus more
on the "contribute" link as well.
This isn't an issue template; it's a stub that will be auto-closed by CI
and is meant to discourage future package requests, and encourage more
pull requests.
See the full discussion on https://github.com/NixOS/nixpkgs/issues/425040.
Signed-off-by: Fernando Rodrigues <alpha@sigmasquadron.net>
This only happens when the label workflow runs in pull_request context
*and* from within nixpkgs (not a fork). This is the case for dependabot
updates.
When a user deletes their account, they appear as a "ghost user". This
user is represented as `null` on API requests. If such a user had posted
a review before, this breaks a few places, which assume to be able to
access `user.login`.
The owners check is not reproducible, because it depends on the state of
the NixOS org on GitHub. Owners can rename their accounts or they can
leave the organisation and access to Nixpkgs can be removed from teams.
All of this breaks the owners check for reasons unrelated to the PR at
hand.
This PR makes the check for the owners file conditionally required: Only
when the ci/OWNERS file is actually modified a failed check will block
merging the PR. When that's not the case, the check will still fail
visibily in the checklist, but the failure can be ignored.
This is especially relevant for the Merge Queue, which should not be
entirely blocked whenever any of these events happen.
Also, it allows passing the checks in a fork when testing, where the
owners check will *always* fail, because the respective teams and
members are never part of the "user org" that a fork is.
The required status checks should depend on exactly one workflow,
triggered via pull_request_target or merge_group. Anything that is
triggered by pull_request is for testing purposes of the workflows
themselves only.
Posting the status manually allows us to avoid the strange "skipped ==
success" logic and properly skip the `unlock` job for pull_request
events in the next commit.
This should be much easier to understand than the previous logic.
When a contributor mistakenly sets the wrong target branch for a Pull
Request, this can lead to bad consequences for CI. Most prominent is the
mass ping of codeowners, that is already handled in
`ci/request-reviews/verify-base-branch.sh`. But there are other things
that go wrong:
- After eval, a mass ping of maintainers would still be possible, in
theory. Practically, this doesn't happen, because we have a limit of 10
reviewer requests at the same time.
- This will most often contain a change to `ci/pinned.json`, thus the
full Eval matrix of all Lix/Nix versions will be run, burning a lot of
resources.
- The PR will be labelled with almost all labels that are available.
We can improve on the current situation with some API calls to determine
the "best" merge-base for the current PR. We then consider this as the
"real base". If the current target is not the real base, we fail the
prepare step, which is early enough to prevent all other CI from
running.
This moves the no-channel-base check into the prepare script to exit
early and prevent all of CI to run against those branches. We also
provide better output by posting a "Changes Requested" review, using the
existing infrastructure from the old cherry-picks check.
The review will be dismissed automatically once the branch has been
corrected, because the commits check will run and do it.
