Skip to content

merge queue: checking #13260 on main (e5898fa), stacked on #12998, #13137 and #13267 - #13275

Closed
mergify[bot] wants to merge 9 commits into
mainfrom
mergify/merge-queue/1bbce514e8
Closed

merge queue: checking #13260 on main (e5898fa), stacked on #12998, #13137 and #13267#13275
mergify[bot] wants to merge 9 commits into
mainfrom
mergify/merge-queue/1bbce514e8

Conversation

@mergify

@mergify mergify Bot commented Oct 7, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

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

#13260 is queued for merge on branch main (e5898fa).

Stacked behind 3 pull requests queued ahead of this batch, not part of it. These checks run on a tip that also carries their commits, so a failure here can come from them as much as from #13260.

Queued ahead of this batch:

This pull request has been created by Mergify to speculatively check the mergeability of #13260.
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:

---
all_scopes: false
checking_base_sha: 1e42983aa9e7e2810f6e506642ebfef8ef9076a3
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 13260
    scopes: []
scopes: []
...

flagendijk89 and others added 9 commits September 25, 2026 10:27
@flagendijk89 @claude
feat(gha-reference): show which inputs each action requires
18df4b2 
The GitHub Action reference lists every input with a default and the actions
that read it, but never says which inputs a step cannot do without. The
`required` badge the template already carried never rendered, because
action.yml has one `required` flag per input, and for an action multiplexed on
`action:` that flag cannot say "required for junit-process, optional for
scopes". So `token` reads the same whether the step uploads test results, which
fails without it, or waits for jobs, which never looks at it.

The action's description is the contract, so that is where the answer goes: an
input description may end with a `Required by: junit-process, scopes` line. The
parser reads that line into `requiredBy`, strips it from the rendered
description, keeps only names some step actually runs for, and treats
`required: true` as required by every reader. Nothing on the page is written
here; it is still read off the vendored action.yml.

Rendering: each action card splits its inputs into "Required inputs" and
"Optional inputs" when it has any required one, an input required by only some
of its readers gets a "Required by" row, and an input required by every reader
gets the same `required` badge the CLI reference uses. The label reuses the
CLI reference's badge treatment so the two generated pages match.

The vendored action.yml at v25 carries no `Required by` lines yet, so this
renders identically until the upstream action ships them and the file is
re-vendored. Tests cover the parser on an inline action.yml, including a name
the line gets wrong being dropped rather than published.

Part of MRGFY-9480.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Change-Id: I5ce9195ddd7926758e62f98464cad4b749da3eee
Claude-Session-Id: 64bcad22-d930-4090-a7bf-09a9a5cb10fb
@jd @claude
docs(workflow): recapture the branch protection injection shot on the…
201f3ec 
… merge action page

The screenshot under "Branch Protection Conditions" showed
`#approved-reviews-by>=1` and `#changes-requested-reviews-by=0` tagged
[GitHub branch protection]. Mergify no longer injects either: a branch
protection that requires an approving review now injects the single
`github-review-approved` condition the paragraph above the image already
describes.

The new shot is a merge rule in the Mergify Summary check on the public
mergify-sandbox/docs-captures repository, for a pull request targeting a
branch whose protection requires one approving review. It shows
`github-review-approved` with its [GitHub branch protection] tag, the
merge requirements and the configuration change block. The alt text now
says what the image shows.

Fixes Mergifyio/ci-bot#685

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: I01fd5cc0da57c414584171bf4e2180318fea8a51
@jd @claude
docs(merge-queue): say queue commits are signed, so a signatures rule…
b905ac5 
…set works on queue branches

The rulesets page said a `required_signatures` rule rejects every push to a
queue branch because the commits Mergify composes for it are unsigned. On the
hosted service those merge commits are now signed and committed as
`Mergify <commit-signer@mergify.com>`, so GitHub shows them as Verified, and
the queue no longer refuses such a ruleset up front.

The section now says what is true:

- a signature rule on the queue branches works without a bypass on the hosted
  service, and the signed commits also pass a rule on the base branch with
  `merge-batch` or batch-PR `fast-forward`;
- what can still be refused: a queued pull request's own unsigned commits
  (typically from a fork), which the author has to sign rather than bypass;
  the unsigned commits of the `squash`, `backport` and `copy` actions; and an
  on-premise installation, which does not sign;
- a workflow that verifies signatures against its own keyring needs Mergify's
  public key from https://github.com/mergify-commit-signer.gpg, next to
  GitHub's web-flow key;
- the bypass-actor remedy stays, scoped to the cases that remain.

The compatibility table row for `required_signatures` changes to match. The
section heading and its anchor are unchanged, since other links point to it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: Ib67fb4464993e86510ccbe9e7f6c3d2b7494e05d
@jd
Merge branch 'main' into devs/frank/docs-gha-reference-required-input…
bd7926d 
…s/I5ce9195ddd7926758e62f98464cad4b749da3eee
@flagendijk89 @claude @jd
docs(gha): show a job summary that matches the example workflow
5b94171 
The Job Selection walkthrough ends on an image of the workflow run's summary,
and that image described a different workflow from the one printed above it.
The example defines `detect-scopes`, three test jobs and `ci-gate` over the
scopes `frontend`, `api` and `docs`; the image showed jobs called `changes` and
`all-greens`, scopes called `docker` and `merge-queue`, and a red cross against
every scope, which reads as a failed run rather than as "nothing matched". It
was a dark-theme capture on a page that is light by default, and it predated
two changes in what the action prints: the scope summary now abbreviates the
base and head to seven characters and names the source of the refs, and the
gate job's status list has a different layout.

The image now shows the example itself: a pull request that touched the
frontend and the docs, so `docs` and `frontend` match, `api` does not, and
`api-tests` is skipped while `ci-gate` still succeeds. That is the same run the
diagram earlier in the section draws.

It is a rendered recreation, not a capture of a live run. Its text follows the
two programs that write these summaries at the versions the page documents: the
scope table from the Mergify CLI's scope-detection summary, and the gate
summary from re-actors/alls-green at the commit gha-mergify-ci v26 pins, which
is where the "allowed to be skipped" line and the per-job symbols come from.
The info glyph on that line is drawn, because the character the action prints
has no glyph in the fonts available here. Replace it with a capture from the
sandbox whenever one is convenient; the filename and the alt text can stay.

The sentence that introduced the image said only that annotations "can be seen
in your GitHub Actions jobs summary". It now says which two jobs write to the
summary and what each one lists, and the alt text describes what the image
shows instead of naming it.

Part of MRGFY-9849.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Change-Id: I92d50e94f8378eb5fd7267bd1b2190fd69dff335
Claude-Session-Id: 64bcad22-d930-4090-a7bf-09a9a5cb10fb
@mergify @mergify-commit-signer
Merge of #12998
b849d95
@mergify @mergify-commit-signer
Merge of #13137
34bbcdd
@mergify @mergify-commit-signer
Merge of #13267
1e42983
@mergify @mergify-commit-signer
Merge of #13260
e3c986e
@mergify
mergify Bot deployed to Mergify Merge Protections October 7, 2026 07:29 Active
@mergify mergify Bot mentioned this pull request Oct 7, 2026
Merged
@mergify mergify Bot closed this Oct 7, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/1bbce514e8 branch October 7, 2026 07:32

This branch was successfully deployed

1 active deployment
Mergify Merge Protections — e3c986eb Deployed Oct 7, 2026 by mergify[bot]
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.

2 participants

@flagendijk89 @jd