Paths within a --expr expression are relative to the script file,
while relative paths in NIX_PATH are relative to the caller's CWD.
We want the Nixpkgs import to be relative to update-pinned.sh itself,
so that it does not matter where it's executed from.
See https://github.com/NixOS/nixpkgs/issues/425551
(cherry picked from commit 37aac0fb06)
With a dependency chain like
a -> b -> c
it was not possible to e.g. add a `meta.problems.removal` to b, because that would cause b to be entirely unavailable as a dependency.
This PR slightly lifts that restriction by allowing both a and b to be marked with such a problem without causing a CI failure.
This is useful for:
- Having a problem on a package that needs to be removed but still has dependents (which then also need a problem)
- Having a problem on a package that is aliased under another attribute, which counts as a dependency
(cherry picked from commit bf80cf0f2e)
This adds the small cost of building 'nixos-render-docs', a small python package.
For the benefit of improved iteration speed during refinement of the docs rendering
See: https://github.com/NixOS/nixpkgs/pull/535662 for motivation
(cherry picked from commit 77ea5f7ed3)
`bot.js` already pulls reviews via GraphQL for the approval-count
labels. Move that fetch above the `handleMerge` call, add `commit
{ oid }` to the query, and pass the result through. `handleMerge` no
longer issues its own `listReviews` REST call.
While here, the `approvals` set is now derived from the same reviews
data. Two upsides:
- A reviewer who approved and was later dismissed no longer counts
towards the approval check; their review now surfaces with state
DISMISSED instead of leaving a stale `reviewed` event behind.
- `events` is no longer needed by `runChecklist` (it was only feeding
the approvals filter); the parameter is dropped from both call
sites. `handleMerge` still uses `events` for tracking the latest
push and merge-command comments.
Also drop the redundant `user` truthy checks (and the stale "some
users have been deleted" comment) in `runChecklist`. The GraphQL
query uses `author { ... on User { login id } }` and bot.js then
filters via `r.user?.login`, so by the time reviews reach
`runChecklist` every entry already has a populated `user`. Verified
by querying real PRs: bots surface as `{__typename: "Bot"}` (no
`login`/`id`, filtered out by bot.js), and deleted accounts surface
as the "ghost" user (login `"ghost"`, id `10137`), which passes the
filter but matches no committer - harmless for both checks.
Assisted-by: claude-code with claude-opus-4-8[1m]-high
(cherry picked from commit 0c1c3d4813)
The previous tip ("Sometimes GitHub gets stuck after enabling Auto
Merge") didn't explain why nothing happens immediately after the bot's
"Enabled Auto Merge" reply, leaving maintainers unsure whether to wait
or intervene. Spell out that Auto Merge waits for required CI before
queueing, that a later CI failure leaves the PR un-queued until it is
fixed, and link to GitHub's documentation; keep the existing "leave
another approval" workaround for the rare cases where Auto Merge stalls
after CI completes.
Assisted-by: claude-code with claude-opus-4-8[1m]-high
(cherry picked from commit 6f9325fb5d)
A "changes requested" review from a committer blocks both the merge
queue and auto-merge, but unlike approvals it isn't auto-dismissed
when new commits are pushed. Surface it as a checklist item so the
bot's reply explains the block instead of silently enabling
auto-merge that will never trigger.
Implementation pulls every review for the PR via `listReviews` and,
for each committer, takes the latest review whose state is
`APPROVED`/`CHANGES_REQUESTED`. The check fails if any committer's
latest stance is `CHANGES_REQUESTED`. Other review states fall out
naturally:
- A dismissed review surfaces as `DISMISSED`, so a committer
dismissing their own changes-requested review unblocks the PR.
- A comment-only follow-up surfaces as `COMMENTED`, so it doesn't
override an earlier actionable review - the prior stance still
stands until the committer explicitly approves or requests changes
again.
Assisted-by: claude-code with claude-opus-4-8[1m]-high
(cherry picked from commit b94b44d3f9)
The merge bot falls back to GitHub Auto Merge whenever the merge queue
won't accept a PR yet. That is the right move while CI is still
running, but pointless once CI has already failed: Auto Merge can never
trigger, and fixing CI requires a new push, which invalidates the merge
command anyway (the bot only acts on comments after the latest push).
Fetch the `no PR failures` commit status and, when the merge-queue
enqueue fails, branch on it. If CI has already failed
(`error`/`failure`), skip Auto Merge and reply that a fresh
`@NixOS/nixpkgs-merge-bot merge` comment is needed once CI is green
again. Otherwise (pending or missing status) enable Auto Merge as
before.
`merge()` now returns `{ reaction, messages }` so the CI-failure path
can leave a thumbs-down reaction rather than the rocket used for an
actual merge.
Closes#512554.
Assisted-by: claude-code with claude-opus-4-8[1m]-high
(cherry picked from commit da97bf8423)
All remaining unquoted uses of or as an identifier were removed in
PR #475723, so this rule can now be enabled to prevent it from coming
back.
(cherry picked from commit 45e309e3a3)
The performance comparison summary previously stated it compared against
"its pull request base branch (e.g., 'master')" regardless of the actual
base branch.
Plumb the base branch classification computed in prepare.js through the
eval workflow to the `compare` derivation so the summary names the real
base branch (e.g. "staging-25.11"). The local `eval.full` helper defaults
to "master", matching its touched-files convention.
Assisted-by: claude-code with claude-opus-4-8[1m]-high
(cherry picked from commit a100d091a0)
Use nixpkgs from the current directory because otherwise the npins used
could be outdated.
Also run npins upgrade as part of the script.
(cherry picked from commit 089cd8fbac)
Previously the eval comparison was skipped entirely when packages were
added or removed between revisions, leaving only a "stats were skipped"
message. cmp-stats already joins on the stats chunks present in both
revisions, so a comparison can still be produced. Always run it and add
a GitHub note caveating that the figures are approximate when the
package sets differ.
Assisted-by: claude-code with claude-opus-4-7[1m]-xhigh
(cherry picked from commit 25f9394b8a)
New feature: revoke review requests from a reviewer when the reason they
were review-requested in the first place is gone (e.g. force-pushed),
while preserving reviewers who voluntarily engaged.
