merge queue: checking #13034 on main (18694ef), stacked on 4 pull requests ahead

src/content/docs/ci-insights/flaky-test-detection.mdx

@@ -37,7 +37,7 @@ digraph {
   subgraph cluster_commit1 {
     class="batch";
     label="Commit abc123";
-    commit1 [label="test_something2", shape=oval, class="config"];
+    commit1 [label="test_something", shape=oval, class="config"];
   }
   run1 [label="Run #1 — tests pass", class="merged"];
   run2 [label="Run #2 — tests fail", class="failed"];

src/content/docs/ci-insights/jobs.mdx

@@ -50,3 +50,10 @@ and related test results.
   duration to see whether the failure correlates with a performance
   change.
 :::
+
+## Data Retention
+
+CI Insights keeps 30 days of job history. The free tier keeps only the last 24
+hours, so a date range reaching further back returns nothing older than that
+rather than an error. Both views show a banner when your plan is on the shorter
+window.

src/content/docs/merge-queue/batches.mdx

@@ -157,9 +157,10 @@ batch failures cheaper to resolve: when a batch fails and has to be
 [split](#handling-batch-failure-or-timeout), related changes stay together and
 unrelated pull requests aren't dragged into someone else's failure.
 
-This is the default merge queue behavior (serial mode). Parallel mode groups
-pull requests strictly by scope instead. See [Queue
-Modes](/merge-queue/queue-modes#parallel-mode).
+This is how the default [serial mode](/merge-queue/queue-modes#serial-mode) and
+[isolated mode](/merge-queue/queue-modes#isolated-mode) both build their
+batches. [Parallel mode](/merge-queue/queue-modes#parallel-mode) is the
+exception: it groups pull requests by their exact set of scopes instead.
 
 Grouping applies these rules in order of precedence: it never overrides
 [priority](/merge-queue/priority) or queue order, it always keeps a
@@ -285,6 +286,11 @@ queue_rules:
     merge_method: fast-forward
 ```
 
+Fast-forward only works in serial mode. [Parallel and isolated
+modes](/merge-queue/queue-modes) merge their batches independently, which
+fast-forward cannot do, so Mergify rejects a configuration that combines them
+rather than failing at merge time.
+
 See [Merge Strategies: Fast-Forward](/merge-queue/merge-strategies#fast-forward)
 for a detailed explanation of how fast-forward works in both inplace and
 batch-PR modes.
@@ -774,13 +780,21 @@ queue processing, consider the following points for an optimal setup:
 
 ### Branch Protection Settings
 
-Batches require the branch protection setting *Require branches to be up to
-date before merging* to be disabled. If your team requires a linear history,
-you can set the queue option `merge_method: rebase`.
-
-For details on why and how to resolve this, see [GitHub Rulesets
-Compatibility: Require Branches to Be Up to
-Date](/merge-queue/github-rulesets#require-branches-to-be-up-to-date).
+The branch protection setting *Require branches to be up to date before
+merging* conflicts with a queue that tests its batches on a temporary batch pull
+request. GitHub enforces the setting against the original pull requests, not
+against the batch that was tested, so it blocks the merge. Disabling the setting
+is the simplest resolution, though not the only one. [In-place
+checks](#in-place-checks-no-batch-prs) build no batch pull request and never hit
+the conflict, but they require `batch_size: 1`, so a queue that batches cannot
+use them.
+
+That setting is not what keeps your history linear: if your team requires a
+linear history, set the queue option `merge_method: rebase`.
+
+See [GitHub Rulesets Compatibility: Require Branches to Be Up to
+Date](/merge-queue/github-rulesets#require-branches-to-be-up-to-date) for why
+the conflict happens and for every resolution.
 
 ### Queued PR Changes
 

src/content/docs/merge-queue/direct-merge.mdx

@@ -108,6 +108,10 @@ request and a full CI run.
 - **The pull request is alone at the front of its lane.** Nothing the queue has yet to merge sits
   between it and the base branch.
 
+- **The queue tests in a batch pull request.** A queue running [in-place
+  checks](/merge-queue/batches#in-place-checks-no-batch-prs) tests the pull request on its own
+  branch instead, so there is no batch pull request for Direct Merge to skip.
+
 - **The queue does not use [two-step CI](/merge-queue/two-step).** Two-step CI defers the heavy
   suite to the queue on purpose, so the pull request's own CI is not the full signal.
 

src/content/docs/merge-queue/github-rulesets.mdx

@@ -72,7 +72,9 @@ option on your queue rules:
   both queuing and merging pull requests.
 
 - **`merge`** -- rules are injected as merge conditions, checked after the
-  queue has tested the pull request.
+  queue has tested the pull request. See [Injection Mode `merge` and Required
+  Status Checks](#injection-mode-merge-and-required-status-checks) for when this
+  mode conflicts with a ruleset.
 
 - **`none`** -- rules are not injected at all. This mode requires a
   `merge_bot_account` on the queue rule, since Mergify must merge with
@@ -413,7 +415,35 @@ tested. This setting blocks the merge.
   branch directly and is not affected by this setting.
 
 - **Alternative:** use [in-place checks](/merge-queue/batches#in-place-checks-no-batch-prs),
-  which test PRs on their own branch without creating temporary batch PRs.
+  which test PRs on their own branch without creating temporary batch PRs. Note
+  that in-place checks require `batch_size: 1`, `max_parallel_checks: 1` and
+  serial mode, so this resolution means giving up the batches or parallel checks
+  that caused the conflict rather than keeping them.
+
+### Injection Mode `merge` and Required Status Checks
+
+With [`branch_protection_injection_mode: merge`](#controlling-injection), the
+queue runs the required checks on the batch PR and then merges the original one.
+GitHub enforces the ruleset's `required_status_checks` rule against that original
+pull request, which never carried those checks, so it refuses the merge and the
+queue reports an incompatibility error.
+
+This only arises when the batch PR is not itself what lands. A queue using the
+[`fast-forward`](/merge-queue/merge-strategies#fast-forward) or
+[`merge-batch`](/merge-queue/merge-strategies#merge-batch) merge method merges the
+batch PR, so GitHub enforces the checks against the head that ran them. [In-place
+checks](/merge-queue/batches#in-place-checks-no-batch-prs) are clear too: they
+run on the original pull request, so again the head that lands is the head that
+ran the checks.
+
+**Resolution:**
+
+- **Preferred:** add Mergify as a bypass actor on the ruleset, as the
+  [recommended setup](#recommended-ruleset-setup) already calls for. Every
+  bypass mode clears this one.
+
+- **Alternative:** leave `branch_protection_injection_mode` at its default,
+  `queue`.
 
 ### Review Requirements and Fast-Forward