commits
(cherry picked from commit 41a2f2ad56fc94f33fa30eb1206620e67ad88ad3)
Build is failing with newer versions; From upstream's readme:
The bridge supports any version of Node.js between v18.X - v20.X.
(cherry picked from commit 02b305e083ade13e61496b16872d7375392d8da0)
(cherry picked from commit 5b64244f3fe95884b769ee9fa7ae6e74e7abff6c)
Since process doesn't need to run on push events anymore, we can just as
well remove it entirely. The little bit of combine and comparison can be
done in the tag job, even with elevated privileges. That's because those
parts can be done entirely from the target commit, which is trusted.
This saves startup, installing nix, downloading tools and artifacts for
one job. It saves about 1 minute per run, start to finish.
(cherry picked from commit b942fb47dc604f25e4bb710a1072f30e675c973a)
This moves the diff of outpaths into the outpaths job, mainly as a
preparation to allow future improvements. For example, this will allow
running the purity release checks only on changed outpaths instead of
the whole eval.
This also removes the inefficiency introduced in the last commit about
uploading the intermediate paths twice. Now, only the diff is passed on.
Also, technically, the diff is now run in parallel across 4 jobs. This
should be *slightly* faster than before, where outpaths from all systems
were combined first and then diffed. It's probably only a few seconds,
though.
(cherry picked from commit 8a39ce4a48fab9b79be46e9ad28f410749f079d9)
This is an intermediate step towards more efficiency. At this stage, the
outpaths job pulls the result from the matching outpaths job on the
target branch and uploads both results together. The process job then
downloads both results at once and does the comparison as usual.
This is slightly more inefficient, because the intermediate results are
essentially stored as artifacts twice. But that inefficiency will go
away in the next step, this refactor is split to make it slightly more
reviewable and testable.
On the other side, this allows us to save the process job on push events
entirely, which is a win, because most of it is setup and nix download
anyway.
(cherry picked from commit a6b659b08a58ed914c52a6042ad8b92ece8dea03)
We don't really need to run the combine and comparison steps from the
untrusted merge commit. By switching to the trusted target commit, we
can avoid adding another worktree - and lay the foundation to later do
those steps in the tag job, which has access to secrets.
(cherry picked from commit 13f5aa304ef68e02a35d0a26812217bb32d73be2)
Everything is a result, especially when nix-build uses "result" as its
default output. This becomes confusing, when re-wiring the different
parts later.
Thus, consistently name those things after some of their properties and
avoid the term result.
(cherry picked from commit b2579d36ffbf8691ed1e9fcdc001d5880277ae14)
The old endpoint seems unreachable. We are now pointing to the wiki instead.
Closes #407648
(cherry picked from commit 35e5c22876c54a09d1fb1b6e60d8333c4d60fc2a)
(cherry picked from commit 274bdab79f2e325d7500eb6a4e2f3930d73c2f35)
(cherry picked from commit 00ca994bbb35f4bfa6a7c6ec63a1cc68434e76db)
This makes checking out the nixpkgs repo even more consistent and almost
forces us to use the trusted/untrusted path pattern.
(cherry picked from commit 0e1c284b1321a3a2cacf96068fdba7b59ed0602b)
We have added nixpkgs-vet as a regular package to nixpkgs a while ago,
so we can now use it from pinned nixpkgs. This avoids pulling a
platform-specific binary version from upstream.
This change also allows to run the tool easily locally, the same way as
other tools:
nix-build ci -A nixpkgs-vet
This will do a full check of the repo with the exception of
nixpkgs-vet's "ratchet" checks: Those depend on having two branches to
compare, but the default is to only look at the head branch. Those
ratchet checks will still be run in CI, though.
(cherry picked from commit 942c377476675848155e860b9d41d869589b8a47)
By consistently checking out nixpkgs into the same location in every
workflow, it's easier to reason about the different workflows at once.
We also use crystal-clear names to make clear, which checkouts are
considered trusted, because they only contain target-branch-code and
which checkouts are untrusted, because they contain code from the head
branch. By naming the checkout directories trusted/untrusted, it's
obvious at the call-site.
One example of where we likely did the wrong thing is the nixpkgs-vet
workflow: Fetching the toolVersion from the untrusted checkout opens the
door for an injection into the download URL, thus code could be
downloaded from anywhere. This is not a problem, because this workflow
does not run with elevated privileges, but it's a scary oversight
nonetheless.
(cherry picked from commit 6720d254294220cdfce18c3f981a8aabffb3de94)
Using core.setOutput is much nicer than having to parse the json
"result" on the outside. This also avoids some very odd errors, when the
result can, for unknown reasons, *not* be parsed as JSON later on.
Also avoiding a bit of duplication between the "if mergeable" branches.
(cherry picked from commit 539e8d4f66323b87aa1b8e715ec01b9f5199ca82)
In PRs with multiple commits and merge conflicts the logic "targetSha ==
immediate parent of mergedSha" doesn't hold anymore. The head and base
commits of the PR's branch have some commits inbetween them, instead.
Before this change, we'd get a "fatal: invalid reference" on the
"worktree add". Now, not anymore, because we fetch the right commit
directly.
(cherry picked from commit cd9a22d7530baf33890971b01af8798069c3fea9)
(cherry picked from commit 4bd7a0155f8fd5f3d0ec12abb1d4915cd42bc23c)
(cherry picked from commit 7062080823125e81da5132751e3b6b77511ddbf8)
(cherry picked from commit eb3dd361dad7dbec937de5e3919fa08b17e1adad)
(cherry picked from commit e4ee2c14f04d6248844fd5fa157400390b60270e)
(cherry picked from commit a5a7b272ee007aabade4b6e89c7609bc9ac88b0f)
(cherry picked from commit b061acba4cedb739faa773ffe001d38af088333d)
(cherry picked from commit 6dfe996ec1e246e173b73194a8be0533bf982663)
(cherry picked from commit f07903a00be7a017533534318a53ae982e719f4c)
(cherry picked from commit 39e8a0516816f96f35f9d0b139b11a9dd9c460a1)
(cherry picked from commit ddde68fb87909d89f57196ac33f00498670a56b8)
(cherry picked from commit 35ab705fff6f4c1b2dca0125347db3d80b358e62)
(cherry picked from commit f49642dccc26790506173ad72af67d1faff77c09)
(cherry picked from commit 28eb5dec4b034989cf758f74a1ea976c9c43594d)
(cherry picked from commit f36c564937b99661a74e2343b4291043b33079a7)
(cherry picked from commit 869289b1bac186f058afa8de5ecbb7fe0695ac67)
(cherry picked from commit 1ca8ec60b04d7c274be11d9f8e1858ac469fc85b)
(cherry picked from commit 0a51a163ca3eea7483244decefeee662dcde2694)
(cherry picked from commit 487d1383c883c5707bdece8a9c95b00f6bad7a1e)
(cherry picked from commit a2d01ca3d18cb5ce7e51ea6c1afd94ebd3db5e1e)
(cherry picked from commit 41a2f2ad56fc94f33fa30eb1206620e67ad88ad3)
Since process doesn't need to run on push events anymore, we can just as
well remove it entirely. The little bit of combine and comparison can be
done in the tag job, even with elevated privileges. That's because those
parts can be done entirely from the target commit, which is trusted.
This saves startup, installing nix, downloading tools and artifacts for
one job. It saves about 1 minute per run, start to finish.
(cherry picked from commit b942fb47dc604f25e4bb710a1072f30e675c973a)
This moves the diff of outpaths into the outpaths job, mainly as a
preparation to allow future improvements. For example, this will allow
running the purity release checks only on changed outpaths instead of
the whole eval.
This also removes the inefficiency introduced in the last commit about
uploading the intermediate paths twice. Now, only the diff is passed on.
Also, technically, the diff is now run in parallel across 4 jobs. This
should be *slightly* faster than before, where outpaths from all systems
were combined first and then diffed. It's probably only a few seconds,
though.
(cherry picked from commit 8a39ce4a48fab9b79be46e9ad28f410749f079d9)
This is an intermediate step towards more efficiency. At this stage, the
outpaths job pulls the result from the matching outpaths job on the
target branch and uploads both results together. The process job then
downloads both results at once and does the comparison as usual.
This is slightly more inefficient, because the intermediate results are
essentially stored as artifacts twice. But that inefficiency will go
away in the next step, this refactor is split to make it slightly more
reviewable and testable.
On the other side, this allows us to save the process job on push events
entirely, which is a win, because most of it is setup and nix download
anyway.
(cherry picked from commit a6b659b08a58ed914c52a6042ad8b92ece8dea03)
We don't really need to run the combine and comparison steps from the
untrusted merge commit. By switching to the trusted target commit, we
can avoid adding another worktree - and lay the foundation to later do
those steps in the tag job, which has access to secrets.
(cherry picked from commit 13f5aa304ef68e02a35d0a26812217bb32d73be2)
Everything is a result, especially when nix-build uses "result" as its
default output. This becomes confusing, when re-wiring the different
parts later.
Thus, consistently name those things after some of their properties and
avoid the term result.
(cherry picked from commit b2579d36ffbf8691ed1e9fcdc001d5880277ae14)
We have added nixpkgs-vet as a regular package to nixpkgs a while ago,
so we can now use it from pinned nixpkgs. This avoids pulling a
platform-specific binary version from upstream.
This change also allows to run the tool easily locally, the same way as
other tools:
nix-build ci -A nixpkgs-vet
This will do a full check of the repo with the exception of
nixpkgs-vet's "ratchet" checks: Those depend on having two branches to
compare, but the default is to only look at the head branch. Those
ratchet checks will still be run in CI, though.
(cherry picked from commit 942c377476675848155e860b9d41d869589b8a47)
By consistently checking out nixpkgs into the same location in every
workflow, it's easier to reason about the different workflows at once.
We also use crystal-clear names to make clear, which checkouts are
considered trusted, because they only contain target-branch-code and
which checkouts are untrusted, because they contain code from the head
branch. By naming the checkout directories trusted/untrusted, it's
obvious at the call-site.
One example of where we likely did the wrong thing is the nixpkgs-vet
workflow: Fetching the toolVersion from the untrusted checkout opens the
door for an injection into the download URL, thus code could be
downloaded from anywhere. This is not a problem, because this workflow
does not run with elevated privileges, but it's a scary oversight
nonetheless.
(cherry picked from commit 6720d254294220cdfce18c3f981a8aabffb3de94)
Using core.setOutput is much nicer than having to parse the json
"result" on the outside. This also avoids some very odd errors, when the
result can, for unknown reasons, *not* be parsed as JSON later on.
Also avoiding a bit of duplication between the "if mergeable" branches.
(cherry picked from commit 539e8d4f66323b87aa1b8e715ec01b9f5199ca82)
In PRs with multiple commits and merge conflicts the logic "targetSha ==
immediate parent of mergedSha" doesn't hold anymore. The head and base
commits of the PR's branch have some commits inbetween them, instead.
Before this change, we'd get a "fatal: invalid reference" on the
"worktree add". Now, not anymore, because we fetch the right commit
directly.
(cherry picked from commit cd9a22d7530baf33890971b01af8798069c3fea9)