This allows the labels workflow to support issue management in two ways:
- New package request can potentially created with a `4.workflow:
auto-close` label immediately and be closed automatically this way.
- Existing package requests can be bulk-closed by adding this label.
This has the advantage of posting the explanatory comment at the same
time, which is not possible with regular bulk operations.
(cherry picked from commit b5dee53399)
Not a problem for prepare/commits, but the labels comand will remove the
temp directory again, before it actually runs the command. Nothing good
will come out of that!
(cherry picked from commit eb766e2d51)
When a user deletes their account, they appear as a "ghost user". This
user is represented as `null` on API requests. If such a user had posted
a review before, this breaks a few places, which assume to be able to
access `user.login`.
(cherry picked from commit 41ae23c0e7)
When a contributor mistakenly sets the wrong target branch for a Pull
Request, this can lead to bad consequences for CI. Most prominent is the
mass ping of codeowners, that is already handled in
`ci/request-reviews/verify-base-branch.sh`. But there are other things
that go wrong:
- After eval, a mass ping of maintainers would still be possible, in
theory. Practically, this doesn't happen, because we have a limit of 10
reviewer requests at the same time.
- This will most often contain a change to `ci/pinned.json`, thus the
full Eval matrix of all Lix/Nix versions will be run, burning a lot of
resources.
- The PR will be labelled with almost all labels that are available.
We can improve on the current situation with some API calls to determine
the "best" merge-base for the current PR. We then consider this as the
"real base". If the current target is not the real base, we fail the
prepare step, which is early enough to prevent all other CI from
running.
(cherry picked from commit 87d9b08ffb)
This moves the no-channel-base check into the prepare script to exit
early and prevent all of CI to run against those branches. We also
provide better output by posting a "Changes Requested" review, using the
existing infrastructure from the old cherry-picks check.
The review will be dismissed automatically once the branch has been
corrected, because the commits check will run and do it.
(cherry picked from commit 0601cf6fd0)
This is the very first step to extending the commits job to do more than
just cherry-picks in the future: It could check reverts or merge
commits, but also the commit message format and more.
Of course, cherry-picks are still just checked on the stable branches as
before. For now, this allows us to run the part that dismisses automated
reviews automatically. This helps us when we do branch related checks in
the prepare step, which would also create such a review. To avoid
cluttering multiple reviews across a PR, we'll want all of these reviews
to be handled by the same code, thus this change.
(cherry picked from commit b6bbf7b250)
The owners check is not reproducible, because it depends on the state of
the NixOS org on GitHub. Owners can rename their accounts or they can
leave the organisation and access to Nixpkgs can be removed from teams.
All of this breaks the owners check for reasons unrelated to the PR at
hand.
This PR makes the check for the owners file conditionally required: Only
when the ci/OWNERS file is actually modified a failed check will block
merging the PR. When that's not the case, the check will still fail
visibily in the checklist, but the failure can be ignored.
This is especially relevant for the Merge Queue, which should not be
entirely blocked whenever any of these events happen.
Also, it allows passing the checks in a fork when testing, where the
owners check will *always* fail, because the respective teams and
members are never part of the "user org" that a fork is.
(cherry picked from commit 956d0a744d)
This workflow runs the PR and Push workflow files on a `pull_request`
trigger. The intent is to test changes to the workflow files
immediately. Previously, these were run directly from the respective
workflow files.
The new approach allows us to move the logic to run this only when
workflow files changed from the pull_request trigger into a job. This
has the advantage that older jobs are cleaned up, when the PR changes
from a state of "workflow files changed" to "no workflow files changed".
This can happen when changing a PR's base from staging to master, in
which case changes from master would temporarily appear in the PR as
changes. When these include changes to workflow files, this would
trigger the PR workflow via `pull_request`. Once the base is changed,
the PR is closed and re-opened, so CI runs again - but since it's on the
same commit and the new run doesn't trigger `pull_request`, the results
of the previous run are still kept and displayed. These results may
include cancelled or failed jobs, which are impossible to recover from
without another force-push.
Checking this condition at run-time is only possible, because we move it
into a separate workflow, turning the `pr.yml` workflow into a re-usable
workflow. This will make sure to skip the whole workflow at once, when
no change was detected, which will prevent the "no PR failures" job from
appearing as skipped - which would imply "success" and make the PR
mergeable immediately. Instead the "no PR failures" job is not shown at
all for this trigger, which is generally what we want.
Do the same for `push.yml` for consistency.
(cherry picked from commit 443f30f811)
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)
Logging objects to stdout is not possible with `core.info`, so we
fallback to `console.log` instead. There's no functional difference for
these anyway.
(cherry picked from commit f94fd64d53)
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 only shows *some* of the additional hints, depending on what the
checks resulted in. Should hopefully reduce confusion a bit.
(cherry picked from commit 91fd9b10ac)
Splits the "occasionally" case into two, depending on whether the commit
has a diff or was not cherry-picked at all. Prepares the next commit,
where these are conditionally shown only.
(cherry picked from commit 2f8ed18c97)
This change allows giving a reason via footer of the commit message for
why this commit is not cherry-picked. This avoids having to "explain"
the automated review comment afterwards - instead, this explanation can
be given immediately when writing that commit.
For example, for an update of `xen` on the stable branch, this could be:
```
xen: 4.19.3-unstable-2025-07-09 -> 4.19.3
[... commit message ...]
Not-cherry-picked-because: unstable is on a different minor version
```
This would then be shown as part of the automated review. The severity
of this will be downgraded from "warning" to "important". We still treat
the review as "changes requested", because it would be very complicated
and noisy to handle two different categories of reviews, some with
requested changes and some with comments only.
An alternative would be to not show this review at all. However, given
that the reviewers expectation on backports should already be "if it's
not a clean backport, the automated review will tell me what to look
at", it seems better to show these and have the committer confirm by
dismissing the review. Otherwise we risk merging actually unreviewed
commits.
(cherry picked from commit bf3607aa87)
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)
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)
