In fb32eb0f29 we moved the checked-out
worktrees into a `nixpkgs` directory. Update the input descriptions to
reflect this.
(cherry picked from commit c25dd6c655)
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.
(cherry picked from commit 55b046451c)
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.
(cherry picked from commit c1b06db57b)
With the latest performance improvements, this only adds up to 1s, but
reduces complexity in managing pinned checkouts explicitly, especially
when we need *both* pinned checkouts in the next commit.
(cherry picked from commit c18d1e4af8)
This fixes problems on darwin, where the new tmpfs folder would not be
fully empty, but git only creates worktrees on fully empty directories.
(cherry picked from commit fb32eb0f29)
This has severity "important", which is not a `core` function. Falling
back to `core.info` for all unknown values now.
(cherry picked from commit 2257beb1d0)
This needs the multiline flags, which enables `^` and `$` to match line
start and line end, not start and end of the whole string.
Not sure how this got past testing when initially merged.
(cherry picked from commit 8ec348d644)
Instead of fetching up to 3 times on each new checkout, we now fetch all
the commits we're going to need at once. Afterwards, we checkout the
different worktrees in parallel, which doesn't give us much, yet,
because it would still be IO-bound on its own. Inconsistent IO
performance on disk is also the biggest limitation for checkout right
now, where checkout times range everywhere from 20s to 40s.
By checking out the worktrees on a tmpfs, the actual checkout only takes
1s and benefits from parallelization. The overall checkout time is now
8-11s, depending on the number of commits.
That's a reduction of 10-30s and we get this speedup for almost every
job in the PR workflow, which is huge.
This potentially has a nice side-effect for Eval, too: Because the repo
is in RAM, Eval seems to run slightly faster, up to 10 seconds less.
(cherry picked from commit 4b4aa628da)
This ensures we don't accidentally use aliases in the nixpkgs shell or
other places that depend on the CI-pinned pkgs instance.
Nixpkgs generally — and CI specifically — do not use aliases, because we
want to ensure they are not load-bearing and can be removed safely.
See: https://github.com/NixOS/nixpkgs/blob/ce9979ec1c/pkgs/top-level/release-outpaths.nix#L28
(cherry picked from commit f646e56d7a)
Currently treefmt-nix is still defaulting `programs.nixfmt.package` to
the `nixfmt-rfc-style` alias. This makes sense, as they do not know for
certain which revision of nixpkgs is in use.
We do know, however, so we can explicitly use the non-alias name.
(cherry picked from commit e981b17a96)
prometheus-smokeping-prober was updated to 0.10.0 in #396980
which introduced a new label `tos` in its metrics.
add it to the failing tests to make them match
the expected metric (and pass) again
you could argue that the tests are a bit too greedy with the way
they match metrics, but I actually like it that way
(cherry picked from commit 2103ba2688)
