Nix 2.3 is marked as insecure and thus not cached anymore.
We'll either need to patch it and cache it again or drop it.
(cherry picked from commit ea970ff3be)
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)
It has only happened once, but the GitHub API suddenly returned a
workflow run from a few weeks back. This lead to quickly hitting the
rate limit for search requests.
Prevent this from happening by going back a day max for the "recently
updated" case. After roughly a day, every PR will have been touched by
the regular batch processing anyway.
Also save a few API requests, by taking bigger chunks of the search
result.
(cherry picked from commit 7f9f7a20b0)
To avoid rendering issues when diffing a markdown file with these
markers in context, just increase the markers length.
(cherry picked from commit 524a47b2b4)
This broke when we moved the check-cherry-picks workflow into the bigger
PR workflow. At this time, the "workflow run" became the whole PR
workflow, which includes many more than just 1 job, thus the assumption
in `jobs[0]` doesn't hold anymore.
(cherry picked from commit c4496912fd)
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)
Previously, when the diff contained a context line with ```, this would
end the code block and entirely break the markdown rendering.
Now we use the html code blocks provided by `core.summary` and properly
escape the content, so that it never escapes via html tags.
(cherry picked from commit b19798c8b0)
This reduces noise that the cherry-pick reviews produce when formatting
related conflicts had to be resolved. We only do this in the
length-limited review comment, though. All changes, including
whitespace, can still be double-checked in the job log if needed.
(cherry picked from commit 40dcbb1483)
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)
This fixes labeling in the context of the `pull_request` trigger. Of
course, this was supposed to immediately label rebuilds after eval
finishes, but we somehow lost this along the way. Rebuilds are still
labeled fairly soon, because the scheduled trigger will pick up the same
PR within 10 minutes again and then apply the rebuild labels. But of
course, immediate is better.
The reason this happened is, that we're looking at `item.pull_request`
only. This is the correct distinction between "issue items" and "pull
request items", which we both get back from the /issues endpoint. But
the payload for the `pull_request*` event doesn't contain this, so
labeling in this case was treated like an issue and skipped the whole
pull request part.
(cherry picked from commit acf5bc2417)
When backporting a PR from master -> 25.05 -> 24.11 in a chain, the last
cherry-pick will have two references to different commits in it. If
there was conflict resolution in the first step, the diff will show up
again in the last step. This can be fixed by comparing against the right
hash - always the last one.
(cherry picked from commit df5b98a38c)
Some jobs purposefully only run on certain base or head branches. By
centralizing the logic, parts of it can easily be re-used later. Also,
this gives them an explicit name and thus makes them easier to
understand.
(cherry picked from commit 7763be5a80)
Instead of deleting each label separately and then making another call
to add new labels, this replaces all labels at once, thus saving API
calls in some cases. Also, the labels are now managed in object-style
compared to the array-style before. This allows putting all the
knowledge about each label into a single place instead of in multiple
places. For example, the rebuild labels had to be special cased in the
workflow before - and the nix code to compare had to match that. Also,
the approval labels had to be considered in the `before` and `after`
phases.
The next commit shows how easy it is to add a new label now.
(cherry picked from commit 5b5b18c875)
Those have not been working since before the migration from OfBorg.
Those `rebuildsByKernel` are an attrset of lists coming from
`groupByKernel` (also see lengthy comment at the top of the file) - thus
we need `lib.elem` instead.
(cherry picked from commit 19ce5d94bc)
Most workflow files are already well formatted, but to make it easier to
keep it that way, we can add yamlfmt.
I personally have a preference for non-indented arrays for YAML, but
wanted to avoid bigger diffs here - the status-quo clearly are indented
arrays.
Some changes are made manually to the get-merge-commit action and the
issue templates. Those would otherwise make yamlfmt misbehave on those.
(cherry picked from commit 8ec23df6f6)
The current setup causes the Security team and the other owners of
.github/workflows to **not** be pinged for the
check-format/codeowners-v2/nixpkgs-vet workflows. This was highly likely
unintended when adding those additional rules, so removing them.
Also, we have some owners looking after `workflows/`, but not `ci/` -
and some the other way around. This doesn't make much sense to me, since
both parts depend on each other very much.
(cherry picked from commit b98e7bb95a)
I think it makes sense for the `stdenv` team to handle review of
changes to these libraries that have substantial effects on the
things in their scope, like the semantics of `stdenv.mkDerivation`,
override interfaces, `meta` handling, and so on. This is already how
`lib/systems/` is handled, and it makes sense to me to extend it.
This would hopefully have helped avoid situations
like <https://github.com/NixOS/nixpkgs/pull/403678> and
<https://github.com/NixOS/nixpkgs/pull/410179>, where the `stdenv`
team was unaware of the original change for weeks.
(cherry picked from commit 1015c45b0e)
It currently fails with this:
```
error: lib.fileset.toSource: `root`
(/tmp/nix-shell-19054-0/tmp.MB62qzBqsj/base) is a string-like value, but
it should be a path instead.
Paths in strings are not supported by `lib.fileset`, use
`lib.sources` or derivations instead.
```
Resolves#416175
(cherry picked from commit 36b76b4141)
Previously we were taking nixVersions and this made external use from
the Lix repo's CI annoying.
We should probably also test other nix versions than stable (i.e. also
latest and Lix), but this involves writing GitHub Actions about it and
maybe not running it on every single PR. Future work.
(cherry picked from commit 332bc64369)
Those checks are part of top-level/nixpkgs-basic-release-checks.nix, but
can be run in CI already to prevent regressions. The idea is to upstream
them into nixpkgs-vet eventually, but we can just as well run them as-is
in the same derivation already.
(cherry picked from commit 247d562379)
This needs to be indented the same way as the remaining code-block,
otherwise the `</details>` is not rendered correctly.
(cherry picked from commit ca5775952e)
Every now and then, the nixpkgs-vet CI job currently fails with one of:
error: creating symlink
'/build/.local/share/nix/root/nix/var/nix/gcroots/profiles' ->
'/build/.local/share/nix/root/nix/var/nix/profiles': File exists
error: SQLite database
'/build/.local/share/nix/root/nix/var/nix/db/db.sqlite' is busy
It's hard to reproduce for me, so just taking a guess with the required
changes.
(cherry picked from commit 3dd14d8a51)
