`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
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
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
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
We use the files endpoint to get a list of all *names* of files touched
in the PR - but this endpoint will also actually download the files /
their diff, too. That's pointless and actually takes quite some time for
huge treewides.
We're just putting in a stop-gap for now, so that we're not burning more
than 1 API requests on this and don't spend so much time on it either. A
limit of 99 files will be more than enough for quite some time - we will
only need to raise this when we're able to represent package sets in
by-name properly and have "package set maintainers", who are not
committers.
Unfortunately it still happens frequently that, after enabling
auto-merge, GitHub is stuck even though all checks have passed, and
doesn't merge the PR. Any contributor can trigger GitHub again with an
approval of the PR - this will then immediately queue the PR for merge.
Adding a hint to the posted comment, should help users through this
without my intervention.
When a user tries to merge a PR, but is not allowed to, it is helpful to
explicitly list the users who *are* allowed. This helps explaining *why*
the merge-eligible label was set.
I objected to this proposal before, because it would incur too many API
requests. But after we have restructured the checklist, this is not
actually true anymore - we can now sensibly run this only when a comment
is posted and not whenever we check a PR for eligibility.
By only ignoring already-handled comments when running non-dry, it's
much easier to look at existing PRs, for which the merge bot already
commented, and iterate on them locally.
It's dry mode anyway, so it won't hurt to get a few more merge comments
in the console output.
We previously used auto-merge first and then enqueued explicitly on the
assumption that auto-merge would fail if the PR was actually in
mergeable state already. This turned out to be false.
Instead, we currently face the problem of auto-merge sometimes getting
stuck. This seems to happen when, at the time of enabling auto-merge,
the required status checks already passed and the PR would be ready to
go - but sometimes GitHub doesn't do it. This *can* be unblocked by
approving the PR again, which seems to run the internal "let's check
whether we can merge this" procedures on the GitHub side again.
However, we can probably also solve this by just explicitly trying to
enqueue the PR first - and only if that fails, fall back to auto-merge.
I previously argued against that, based on a potential race condition,
in which a PR could become ready to merge between these two requests -
at which point the auto-merge operation would fail, if the original
assumption was true. But since we don't observe this, we might as well
switch.
I didn't like r-ryantm "authoring"; so I changed that to "created"
earlier. Arguably, using "opened" is more consistent with what is
actually checked and can consistently be used for both.
The by-name check would previously be green when the
`pkgs/by-name/README.md` file was changed. This would still not mean the
maintainer was able to merge the PR, because there'd be no maintainer
for that file, but the feedback was not 100% accurate.
This allows committers to approve PRs with additional, optional nits
that the author-maintainer can either address or merge immediately
without these changes.
It also allows committers to approve a PR for merge, while still waiting
for other maintainers to give their feedback - they can then merge the
PR directly instead of passing it back to the committer.
While it was already the case that only merge comments *after* the
latest push were acted on, the logic wasn't easy to understand. This
change should make it more obvious, specially in combination with the
next commit, that all steps (comments, approvals, merge) must happen on
the same SHA - the current head SHA of the PR.
All other conditions equal, there is no reason to prevent maintainers
from backporting changes to their packages. Maintainers are probably in
the *best* position to tell whether a certain change is backportable or
not - because they know the package well.
This supports AND on the first and OR on the second level, which is
needed for some follow up work like backports, approval based merges or
trusted maintainers.
We have not observed this merge method being used in practice, yet. Not
in the new bot, not in the old bot. It seems like auto-merge works for
all cases.
No special casing anymore, all conditions are in the same place. This
also has the benefit of hiding the "has maintainers eligible for merge"
condition from comments, because it is only really relevant for
labeling.
We have no chance of getting a token that can request the team endpoints
in the pull_request context. This makes sense, because non-members of
the org are also not allowed to view the teams' memberships.
Thus, just fake an empty team - that's fine for the Test workflow.
Running the nixpkgs-merge-bot in GitHub Actions instead of a separate
workflow has multiple advantages:
- A much better development workflow, with improved testability.
- The ability to label PRs with a "merge-bot eligible" label from the
same codebase.
- Using more data for merge strategy decisions, for example the number
of rebuilds.
This commits re-implements most of the features from the current
nxipkgs-merge-bot directly in the bot workflow. Instead of reacting to
webhook events, this now runs on the regular 10 minute schedule. Some
merges might be delayed a few minutes, but that should not be a problem
in practice.
To give the user early feedback, there are additional workflows running
when a comment or review is posted. These react with "eyes" to make the
user aware that the comment has been recognized.
The only feature not taken over was the size check for files in the PR.
This kind of check is not really relevant for maintainer merges only -
if we want to prevent bigger files from making it into the tree, then we
need a generic CI check, which is out of scope for the merge-bot.
Other than that, everything should be implemented - any omissions are by
accident.
