This allows setting up a custom cachix cache in a contributor's fork.
That's most valuable when working on CI itself, testing and interating
in a fork. It's required when working on cachix related features
directly.
(cherry picked from commit 025424913f)
These two jobs mostly used the same code anyway, so they can easily run
in the same job. This uses fewer resources and avoids running (and
failing) the codeowners review job on Pull Requests from development
branches like staging-next or haskell-updates.
It also opens the door for more improvements later on, for example it
will be much easier to implement a shared reviewer limit for both owners
and maintainers now.
(cherry picked from commit ddf81dead6)
Changes to this file already trigger a run of this workflow via the PR
workflow, we don't need to run this *another* time.
(cherry picked from commit 7f4dd7e2ff)
This runs the "check owners" job as part of the main PR workflow, with
multiple advantages:
- The job doesn't run anymore when undrafting a PR, where it's not
required, because the OWNERS file's contents didn't change.
- A valid OWNERS file is now a requirement to merge a PR.
- The OWNERS file is always checked on the exact same test merge commit
that the remainder of the workflows are running on as well.
(cherry picked from commit 15be04f7a2)
This just moves the code over to ci/github-script to make it easy to
test and iterate on locally.
The name `prepare` is chosen, because the script will be extended with
the other steps from "PR / prepare" next.
(cherry picked from commit c787c66de6)
This action will not be called for push events anymore. For those, the
`push.yml` workflow is run instead, which hardcodes `mergedSha`.
(cherry picked from commit 2087f1be30)
This was an oversight when we introduced the ability for
`get-merge-commit` to take the pre-computed sha as input.
(cherry picked from commit f5c5bc25ea)
Introduces a basic merge queue workflow to initially only run lints.
This will avoid accidentally merging changes which break nixfmt after
its recent update to 1.0.0.
(cherry picked from commit 04c039f993)
The filtered checkout we used before was a nice idea, but only worked
for small numbers of commits in a PR. It would fetch the whole history
initially, but only fetch objects on demand. This turns out to be much
too slow in a PR with 18 commits, regularly hitting the 10 minute
timeout, even when running it locally.
The new approach uses regular checkouts again. In contrast to the old
style, before we switched to the filtered checkout, this only fetches
exactly the commits we need - and all of them at once. This is
significantly faster than both other approaches, and scales much better.
A bigger number of commits doesn't have much of an effect, if any at
all.
(cherry picked from commit 0dff5ad6c5)
This currently times out after 3 minutes. Give it a bit more time. 10
minutes might be excessive, but we only really want to guard against a
stuck job taking 6 hours.
(cherry picked from commit 17b1c6cb3d)
The `cancelled()` condition seems to only apply when *the whole
workflow* was cancelled. This is not the case when a single job is
cancelled due to timeout.
We can replicate this by checking each needs.result manually.
(cherry picked from commit d1bb35448a)
This currently happens, for still unknown reasons, for the "check cherry
picks" job. The job gets cancelled by GHA mid-way. This should be the
same as an error, because an important check didn't run: Merging should
be blocked and auto-merge should not succeed.
(cherry picked from commit 06f574addf)
The conclusion of the `versions` job propagates from through `eval` to
`compare`, which meant the `compare` job was skipped. No rebuild labels,
no reviewer requests.
Also, we don't want to run eval when `versions` runs, but fails.
(cherry picked from commit 267d5cdf64)
The additional `workflows` permissions are required to backport
Dependabot updates. The permissions had been added to the app a while
ago, but we forgot to actually use them.
(cherry picked from commit bb1529ef6a)
With this change, we start running Eval on all available Lix and Nix
versions. Because this requires a lot of resources, this complete test
is only run when `ci/pinned.json` is updated.
The resulting outpaths are checked for consistency with the target
branch. A difference will cause the `report` job to fail, thus blocking
the merge, ensuring Eval consistency for Nixpkgs across different
versions.
This implements a kind of "ratchet style" check: Since we originally
confirmed that the versions currently in Nixpkgs at the time of this
commit match Eval behavior of Nix 2.3, we can ensure consistency with
Nix 2.3 down the road, even without testing for it explicitly.
There had been one regression in Eval consistency for Nix between 2.18
and 2.24 - two tests in `tests.devShellTools` produce different results
between Lix 2.91+ (which was forked from Nix 2.18) and Nix 2.24+. I
assume it's unlikely that such a change would be "fixed" by now, thus I
added an exception for these.
As a bonus, we also present the total time in seconds it takes for Eval
to complete for every tested version in a summary table. This allows us
to easily see performance improvements for Eval due to version updates.
At this stage, this time only includes the "outpaths" step of Eval, but
not the generation of attrpaths beforehand.
(cherry picked from commit b523f257ac)
The Dependabot update change the hashes to the latest main branch commit
instead of the v5.0.0 tag - also it didn't adjust the tags in the
comments accordingly. Last but not least, one of the references used a
`@v5` reference instead of the commit hash. The latter is probably what
Dependabot tripped on.
(cherry picked from commit 51e6b0e40b)
This avoids downloading results from cachix, when they don't need to be
rebuilt, which just wastes time and resources.
(cherry picked from commit f105ab12f6)
A previous commit from Dependabot did this for all the workflows, but
Dependabot doesn't update the actions folder, apparently.
(cherry picked from commit 46d5594714)
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.
(cherry picked from commit 8a9f0b8a47)
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.
(cherry picked from commit 436d54174d)
This reverts commit f2648b263b.
While the idea to never use swap was fine, in practice this meant that
when nix ran OOM, some other process was killed instead. This lead to
the job not being possible to be cancelled anymore and thus needing to
timeout, before subsequent jobs could be scheduled. This can take up to
6 hours for GitHub Actions by default.
Re-enabling the swap file to catch this case more gracefully. It's still
the goal to never actually *use* the swap file during Eval and just a
safeguard.
Keeping the changed chunkSize and not reverting it - this makes it
slightly less likely to hit the swap file when running with Lix.
(cherry picked from commit 9cde368b4c)
Recent performance tests show that (a) swapping heavily slows down the
Eval job, while (b) lowering the chunkSize does not have an effect on
run-time. It does on memory usage, though - thus we can get rid of
swapping entirely by reducing chunkSize respectively.
(cherry picked from commit f2648b263b)
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`.
(cherry picked from commit bfb20b9fea)
Most of the checks we do for cherry-picks are dismissable warnings, with
one exception: When a commit hash has been found, but this hash is not
available in any of the pickable branches, we raise this with
severity=error. This should also *block* the merge and not be
dismissable. That's because this is a fixable issue in every case.
(cherry picked from commit 1fbcad0434)
This turns the check-cherry-pick script into a github-script based
JavaScript program. This makes it much easier to extend to check reverts
or merge commits later on.
(cherry picked from commit b46cb23251)
Since all github-scripts need to be written in commonjs, we now default
to it by not setting package.json. Support from editors for .js files is
slightly better than .cjs. To still allow using module imports in the
test runner script, we trick node into loading the script itself as a
module again via `--import ./run`.
(cherry picked from commit d11eba1e1d)
This just moves things around to use less specific naming - `labels` is
only *one* script that can potentially be run locally while still being
written in github-script. Later, we can add more.
(cherry picked from commit 6f6c625026)
When a PR is merged and labeled afterwards - with a non-backport label -
the following will happen:
- The first backport job is triggered on the merge.
- The second backport job is triggered on the label event.
- The second job will cancel the first one due to the concurrency group.
- The second job will cancel itself because the label event didn't
contain a backport label.
Both jobs end up cancelled and no backport happens.
We made the backport action idempotent upstream a while ago, so we don't
need to cancel those actions. Instead, we'll run all of them -
subsequent actions running through will just stay silent anyway.
(cherry picked from commit 58a3001a3a)
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.
(cherry picked from commit 261bba1fcd)
Pagination via cursor is required above 10k items. To do so, we store
the current cursor as an artifact and read it back in in the next
scheduled run.
(cherry picked from commit 06a88df620)
We already tried to fix this case earlier, but didn't account for all
cases: A scheduled workflow can also encounter a pull request with
failed PR workflow. This failure doesn't need to be in the Eval part, so
artifacts could *still* be available. To make sure PRs always get
rebuild labels, just ignore the status condition. Either the artifact is
there, or it is not.
(cherry picked from commit 3be9e2afc1)
The `page` number is 1-based, but the remainder might very well be 0.
This lead to not looking at the 100 oldest PRs, ever.
(cherry picked from commit 10c63e5117)
