Skip to content

merge queue: checking main (35dc622), #12455 and #12415 together - #12480

Closed
mergify[bot] wants to merge 5 commits into
mainfrom
mergify/merge-queue/2ade6abc58
Closed

merge queue: checking main (35dc622), #12455 and #12415 together#12480
mergify[bot] wants to merge 5 commits into
mainfrom
mergify/merge-queue/2ade6abc58

Conversation

@mergify

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

Copy link
Copy Markdown
Contributor

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

Branch main (35dc622), #12455 and #12415 are queued together for merge.

This pull request has been created by Mergify to speculatively check the mergeability of #12415.
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: 8e0ba593d3852974cc1e52f534e7dddcaab8aeb2
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 12415
    scopes: []
scopes: []
...

jd and others added 5 commits August 18, 2026 09:18
@jd
fix(ci-insights): name the job-name variable the uploader actually reads
42d7aae 
The CI Insights setup pages and the two matrix helpers disagreed with each other
about how to override the job name a test report is filed under, and none of
them said where the default comes from.

The three setup pages now name `MERGIFY_TEST_JOB_NAME` — the variable the CLI
reads, and the one every framework plugin (pytest, rspec, vitest) already
documents — say where the default comes from on each provider (`GITHUB_JOB` on
GitHub Actions, Jenkins' own `JOB_NAME`, the step label on Buildkite), and show
where to set it. They also state why it matters: the job name is part of a
test's identity, so a scheduled run that reports a different name splits its
results off from the pull request ones.

The GitHub Actions matrix case is stated the way it actually breaks: every leg
of a matrix reports the same job name because they share one `GITHUB_JOB`. The
old text left the reader to infer why an override was needed at all.

The two matrix helpers keep recommending the native override — the action's
`job_name` input and the Buildkite plugin's `job_name` property. Both currently
export `MERGIFY_JOB_NAME`, which no uploader reads, so neither takes effect
today; that is a bug in the three producers of that variable, not something the
docs should route readers around. Fixing them is tracked separately, and the
snippets pin moving tags (the action's `v25`, the plugin's `#v1`), so readers
pick the fix up when those tags move.

The pytest, rspec and vitest pages already agreed with this and are unchanged.

Settles Mergifyio/ci-bot#369.
Part of MRGFY-8720

Change-Id: I96e06bb4500bf9e7664d36d941ef0d962004e9a9
@jd
fix(safety): catch bare tracker ticket refs in the internal-leak scan
dd28773 
`pnpm check:internal-leaks` only ever saw a ticket as a *link*: its
`internal-tracker` rule matches tracker hosts. A bare issue key in prose, in a
code block or in an example value passed cleanly — and one did. The
`mergify tests quarantines add` example on the quarantine page shipped with a
`--reason` string naming an internal ticket, so it has been live on
docs.mergify.com since #11681 and sits in this repository's public history. The
scan reported that exact file clean, before and after.

A bare key is also the case a reviewer is least likely to stop on: inside an
example value it reads as a plausible sample rather than as a leak.

What changed:

- A `ticket-ref` rule for bare issue keys — the two live prefixes, plus the
  lowercase form a branch name carries.
- Prefixes are listed explicitly instead of matching a generic `[A-Z]{3,}-\d+`.
  The generic shape fires on `AES-256`, `WCAG-2` and on a reader's own issue keys
  in a sample config, and that cost lands on every docs contributor; the miss
  cost of an explicit list falls only on a prefix somebody introduces
  deliberately, which is a deliberate act.
- The allow directive now accepts several rule ids. One line can trip two rules
  — a tracker URL carries the key inside it — and such a line previously could
  not be allowed at all.
- The corpus is swept: across the 143 scanned pages that example was the only
  occurrence. Its reason string is now "flaky under load, fix in progress", the
  same wording #12411 uses for the same line, so the two changes do not fight.
  That also removes the prose em dash the example carried inside a CLI string.
- `AGENTS.md` and the `proofread-leaks` skill now list bare keys as well. The
  judgment layer had the same blind spot as the regex, which is why the line
  survived review too.

Verified: the scan exits 1 against the pre-fix file and 0 against the tree,
the full `pnpm test` suite and `pnpm check` are green, and the commit is green
on its own as well as on top of the stack.

One decision is deliberately left open: whether the already-published value
needs scrubbing beyond this branch. It is a ticket prefix rather than a
credential, and it is in the git history of a public repository as well as on
the site, so removing it from the page is all this change claims to do.

Reported as Mergifyio/ci-bot#368.

MRGFY-8721

Change-Id: I847b80676f560fb73f319e2524be6d94207591e8
@jd
fix(docs): send scopes with the flag the CLI documents
f67a34b 
The "Any CI (Mergify CLI)" block on the four monorepo scopes pages ends in
`mergify ci scopes-send --file scopes.json`. `--file` is a deprecated alias, kept
hidden from `--help` and from `public/cli-schema.json` since the CLI was ported
to Rust: it still works, and prints `Warning: --file is deprecated, use
--scopes-json instead.` on every run. So a reader copying the block gets a
deprecation warning for a flag they cannot look up.

`--scopes-json` is the right one, not `--scopes-file`: it reads the
`{"scopes": [...]}` object, which is exactly the shape every page's `jq` filter
writes, while `--scopes-file` expects one scope per line. Confirmed against the
CLI's own reader — it deserializes `scopes` plus an optional `all_scopes`, so the
examples need no change, and `--all` documented on the scopes page stays
consistent with it.

While in the block, the base and head refs now come from `--format json` piped
through `jq` instead of `awk '/^Base:/ {print $2}'` on the default output. The
text format is the human one with no stability promise; `json` and `shell` are
the two contracts meant for scripts. `jq` is already required by all four pages,
so this adds no dependency, and the variables the pages interpolate (`$BASE`,
`$HEAD`) are unchanged.

Checked the rest of the corpus: no other page repeats `--file`, and the scopes
page already documents `--scopes-json`. Nothing outside this repository generates
the snippet — the dashboard and the engine never emit this command.

Reported as Mergifyio/ci-bot#371.

MRGFY-8721

Change-Id: I7691b7156a88b4c43487a2b41f61216c92b5a6a5
@mergify
Merge of #12455
8e0ba59
@mergify
Merge of #12415
f1a1d77
@mergify
mergify Bot deployed to Mergify Merge Protections August 21, 2026 12:56 Active
@mergify mergify Bot mentioned this pull request Aug 21, 2026
Merged
@mergify mergify Bot closed this Aug 21, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/2ade6abc58 branch August 21, 2026 12:58
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

@jd