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.
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.
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.
This is the very first step to extending the commits job to do more than
just cherry-picks in the future: It could check reverts or merge
commits, but also the commit message format and more.
Of course, cherry-picks are still just checked on the stable branches as
before. For now, this allows us to run the part that dismisses automated
reviews automatically. This helps us when we do branch related checks in
the prepare step, which would also create such a review. To avoid
cluttering multiple reviews across a PR, we'll want all of these reviews
to be handled by the same code, thus this change.
Changes to the merge-group workflow should also validate that the file
is hooked up correctly and works - otherwise we risk merging CI changes
that cause the merge queue to fail consistently.
Previously, the test for the push workflow was running on the HEAD
commit of the PR only. It would be better to run it on the merged result
instead, just like any other tests we run in a PR.
This workflow runs the PR and Push workflow files on a `pull_request`
trigger. The intent is to test changes to the workflow files
immediately. Previously, these were run directly from the respective
workflow files.
The new approach allows us to move the logic to run this only when
workflow files changed from the pull_request trigger into a job. This
has the advantage that older jobs are cleaned up, when the PR changes
from a state of "workflow files changed" to "no workflow files changed".
This can happen when changing a PR's base from staging to master, in
which case changes from master would temporarily appear in the PR as
changes. When these include changes to workflow files, this would
trigger the PR workflow via `pull_request`. Once the base is changed,
the PR is closed and re-opened, so CI runs again - but since it's on the
same commit and the new run doesn't trigger `pull_request`, the results
of the previous run are still kept and displayed. These results may
include cancelled or failed jobs, which are impossible to recover from
without another force-push.
Checking this condition at run-time is only possible, because we move it
into a separate workflow, turning the `pr.yml` workflow into a re-usable
workflow. This will make sure to skip the whole workflow at once, when
no change was detected, which will prevent the "no PR failures" job from
appearing as skipped - which would imply "success" and make the PR
mergeable immediately. Instead the "no PR failures" job is not shown at
all for this trigger, which is generally what we want.
Do the same for `push.yml` for consistency.
Both `nix flake check` and `nix-env` are single-threaded, so no reason
to serialize their calls and waste time.
This brings down the runtime for this job from ~1:51 to ~1:27 in my
tests.
The python-updates branch is not a "development" branch in the sense of
ci/README.md's classification. That's because it allows force pushes.
When rewrites are possible, cherry-picking from this branch should not
be allowed, because the commit references will potentially end up out of
sync.
These kind of branches are now termed "Work-in-Progress" branches. Up
until recently these branches didn't work well for Pull Requests
targeting them, because Eval wouldn't run on them with a push event and
thus, Eval in the PR couldn't succeed either. That's now fixed, PRs
towards *any* WIP branch should work correctly.
Instead of uploading the outpaths as artifact, this uploads them via
cachix. Most of all, this makes CI less brittle, because Eval in PRs
will still be able to succeed, even if no workflow run for the push
event could be found on the target branch. It will just take longer.
This also makes moving Eval into the Merge Queue easier to do: When
downloading artifacts from a different run, these would always have to
match on the right event, too. By pulling from cachix, the same workflow
can support target branches with merge queue and without merge queue at
the same time. The latter would still use the push event, while the
former could use the merge_group event.
Last but not least, this should fix Eval on PRs targeting `wip-`
branches and any other branches that the push event doesn't trigger on.
These would never find an Eval result from the target branch and could
never show rebuilds accurately. Now these PRs should work at a slightly
higher runtime cost.
