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)
The previous implementation had two problems:
- When switching from /search to /pulls, we disabled the additional GET
on each single pull request - which causes no test merge commit creation
for all PRs. This means, merge conflicts will not actually be detected.
- By using `item` in the pull-request triggered case, this goes back to
`context.payload.pull_request`, which is the state *at the beginning* of
the workflow run. But this renders our "let's wait 3 minutes before
checking merge_commit_sha" logic void. While we wait for 3 minutes, we
still use the *old* value afterwards...
Just making the extra request every time simplifies the logic and solves
both problems.
(cherry picked from commit 59ac9479e4)
It's necessary to use a combination of different endpoints here, because
the /search endpoint only allows fetching the first 1000 items and will
fail with a higher page number (11+). On the flip side, the /pulls
endpoint doesn't allow counting the total number of results, so we can't
calculate the required page number with its response.
Putting both together should work, though.
(cherry picked from commit 579bfd48da)
This should make sure that the timer is cleaned up, no matter what. This
didn't seem to be the case before, where it would still be stuck
sometimes, when throwing an error somewhere.
(cherry picked from commit ddf3480d49)
When running in a pull_request context, the labels job is part of the
currently running workflow - which will never have succeeded, yet.
Apparently it could be failed already, so in this case we take *any*
workflow run, no matter its state.
(cherry picked from commit ed1fc4c6b3)
To set the stale label properly, we need to consider the right timeline
events only - and their respective relevant timestamps.
(cherry picked from commit d5072dd344)
