Skip to content

merge queue: checking main (9126fe8), #12367 and #12366 together - #12374

Closed
mergify[bot] wants to merge 4 commits into
mainfrom
mergify/merge-queue/f41ad3a292
Closed

merge queue: checking main (9126fe8), #12367 and #12366 together#12374
mergify[bot] wants to merge 4 commits into
mainfrom
mergify/merge-queue/f41ad3a292

Conversation

@mergify

@mergify mergify Bot commented Aug 13, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

🎉 This pull request has been checked successfully and will be merged soon. 🎉

Branch main (9126fe8), #12367 and #12366 are queued together for merge.

This pull request has been created by Mergify to speculatively check the mergeability of #12366.
You don't need to do anything. Mergify will close this pull request automatically when it is complete.

Required conditions of queue rule default for merge:

Required conditions to stay in the queue:

---
checking_base_sha: 8cfd951075e7bac35040c611e9bc68e10f9d3dad
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 12366
    scopes: []
scopes: []
...

sileht and others added 4 commits August 12, 2026 20:23
@sileht
docs(rulesets): list required_deployments as an ignored ruleset rule
34020e1 
The Ruleset Rule Compatibility table put "Used by Merge Protections" in the
`required_deployments` behavior column, directly under two rows reading
"Injected as conditions". Readers compared the rows and concluded Mergify
turns the rule into a merge condition and holds a pull request until the
required deployment succeeds. It does not: the rule is never injected, for
the merge action or the merge queue.

There is nothing for the table to say about it, so the row goes and the rule
joins the Ignored Rule Types list, which already carries the right message:
Mergify will not enforce these, ensure GitHub does.

The intro made the same blanket claim one level up and now says Mergify
injects the supported rules as conditions.

Fixes MRGFY-8644

Change-Id: Id4da85649474e01415e299033832bf04154a172b
@sileht
docs(api): document what the ci application key scope actually grants
fe6c15b 
The `ci` scope was one line about uploading test results and CI Insights
data. A `ci` key also quarantines and unquarantines tests, which decides
whether a failing test blocks a merge, and it works on every repository of
the account with no GitHub repository role attached. A customer handing
that key to their pipeline had no way to know.

Audited the engine routes that accept a `ci` key and rewrote both scope
bullets from that set. The `admin` bullet was wrong too: it claimed full
access to all API endpoints, but the results upload and the Merge Queue
Scopes call accept a `ci` key only.

Two other errors on the page, found while checking the above:

- The `GET /v1/application` response example was stale: the API returns a
  UUID `id`, a `scope` field and `account_scope`, not an integer `id` and
  a `github_account` object.
- The GitHub PAT example called `GET /v1/application`, the one endpoint on
  the page that rejects PATs.

`merge-queue/scopes.mdx` showed its curl with a generic application key,
where only a `ci` key works.

Fixes MRGFY-8645

Change-Id: Ib2790d83483a3d371b595eca06742a010d8ef087
@mergify
Merge of #12367
8cfd951
@mergify
Merge of #12366
facabbe
@mergify
mergify Bot deployed to Mergify Merge Protections August 13, 2026 07:04 Active
@mergify mergify Bot mentioned this pull request Aug 13, 2026
Merged
@mergify mergify Bot closed this Aug 13, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/f41ad3a292 branch August 13, 2026 07:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@sileht