Skip to content

ci: queue PRs in Mergify once verify and Unfret pass #101

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ericlitman wants to merge 2 commits into from
+27 −0
Closed

ci: queue PRs in Mergify once verify and Unfret pass #101

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c27f55c
ci: queue PRs in Mergify once verify and Unfret pass (#100)
ericlitman Oct 1, 2026
635d077
ci: require verify and Unfret on the queued merge commit (#100)
ericlitman Oct 1, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 27 additions & 0 deletions .mergify.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
queue_rules:
- name: default
batch_size: 1
checks_timeout: null
queue_conditions: []
merge_conditions:
- check-success=verify
- check-success=Unfret

merge_protections_settings:
auto_merge_conditions:
- base = main

merge_protections:
- name: Queue ready pull requests
description: Automatically queue non-draft pull requests targeting main after the required gates pass.
if:
- base = main
success_conditions:
- -draft
- check-success=verify
- check-success=Unfret
Comment on lines +19 to +22

@greptile-apps greptile-apps Bot Oct 1, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 PR queues before live verdict

If Unfret does not require the independent live verdict, this rule queues any non-draft PR to main once the two checks pass. The PR can then merge while the live test required by the shipping flow is still in progress. Require that verdict before automatic queuing, or leave queuing to the guarded shipping flow.

Knowledge Base Used: Quality assurance and review

@ericlitman ericlitman Oct 1, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Drafts can't queue: the merge protection requires -draft. AGENTS.md keeps a PR in draft until the installed-candidate evidence is recorded, so marking it ready is the live-verdict gate. That holds only if PRs open as drafts. The live-gate skill in #90 will enforce it by being the step that marks a PR ready. The empty merge_conditions finding is fixed in 635d077.

@greptile-apps greptile-apps Bot Oct 1, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That resolves the concern. With PRs opened as drafts and the live-gate skill being the step that marks them ready after installed-candidate evidence, -draft makes the merge protection a live-verdict gate. The added merge_conditions checks also ensure the queued merge commit reruns both verify and Unfret before merging.

@ericlitman ericlitman Oct 1, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correction to my reply above: the draft convention doesn't close this gap. Unfret doesn't review drafts (drafting cancels an in-flight review), so a PR has to be non-draft to get its Unfret check, and once it is, this rule queues it as soon as verify and Unfret pass, possibly before the live test. The live verdict needs to be its own required check, for example a commit status on the exact head that the #90 skill posts after the installed-harness test, listed in both merge_conditions and the protection's success_conditions.

@greptile-apps greptile-apps Bot Oct 1, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right—the draft convention does not close this gap. Unfret cancels its review for drafts, so the PR must become non-draft before check-success=Unfret can pass; at that point, this protection can queue it without any installed-harness/live verdict.

The live-gate result therefore needs to be an independent status/check on the exact tested head, included in both success_conditions and the queue rule's merge_conditions so it is also rerun and required for the queued merge commit. My previous resolution was incorrect; this finding remains valid.

@ericlitman ericlitman Oct 1, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Refinement, per the review on #104: list live-gate in queue_conditions and the protection's success_conditions only, not in merge_conditions. Mergify validates a temporary queue head that the installed-harness test never sees, so requiring live-gate there would block forever under checks_timeout: null.

@greptile-apps greptile-apps Bot Oct 1, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That refinement is correct. live-gate should be added to the queue rule’s queue_conditions and to the protection’s success_conditions, but not to queue_rules[].merge_conditions. Mergify evaluates merge_conditions against the temporary queued merge commit; because the installed-harness test posts its result only for the original PR head, requiring check-success=live-gate there would leave the queued commit unsatisfied and prevent merging indefinitely when checks_timeout: null. The live-gate therefore controls entry into the queue and protection success, while the queued commit itself only reruns the checks that can report on that commit (verify and Unfret).

@ericlitman ericlitman Oct 1, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Second refinement, from #104's review: putting live-gate only at queue entry still lets a rebuilt queue head merge untested, and non-empty merge_conditions make Mergify create draft batch PRs, which Unfret never reviews. The likely shape: in-place checks (empty merge_conditions, batch_size: 1) plus queue_conditions requiring -draft, verify, Unfret, live-gate, and an up-to-date branch, so the merged tree is the tested tree. Please verify against Mergify's docs before adopting it.

@greptile-apps greptile-apps Bot Oct 1, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docs support the in-place direction, with two qualifications:

  • merge_conditions is the merge-time/speculative-check path. A distinct non-empty set can make Mergify validate a temporary draft/batch PR, and batch_size: 1 alone does not guarantee in-place checks. An empty merge_conditions is appropriate for the single-step path, but in-place behavior also requires serial operation (max_parallel_checks: 1) and batch_size: 1 (along with the other documented eligibility constraints).
  • queue_conditions control admission and continued queue membership. Requiring check-success=live-gate there means that if the tested SHA changes, the PR no longer satisfies the condition and should leave the queue until a fresh verdict is posted. The status must be attached to the exact commit SHA tested.

Thus, the proposed shape is reasonable:

queue_rules:
  - name: default
    batch_size: 1
    checks_timeout: null
    queue_conditions:
      - -draft
      - check-success=verify
      - check-success=Unfret
      - check-success=live-gate
    merge_conditions: []

The queue must also be configured for serial checks (max_parallel_checks: 1), and live-gate should be included in merge_protections[].success_conditions alongside verify and Unfret.

I would not add an invented updated or up-to-date queue condition. Mergify documents GitHub branch protection/rulesets’ strict required-status-checks policy (“Require branches to be up to date before merging”) as the mechanism for that. Since this repository currently has no such protection, enabling it is a separate repository configuration change, not a .mergify.yml condition. Strict protection is also problematic with temporary batch PRs, reinforcing the choice of in-place checks here.

References: queue rules, queue lifecycle, batches and in-place eligibility, and GitHub rulesets.


commands_restrictions:
requeue:
conditions:
- sender-permission >= write
Loading