Repository navigation
merge queue: checking #1881 on main (e265eb5), stacked on #1879 and #1880 - #1886
Closed
mergify[bot] wants to merge 6 commits into
Closed
mergify[bot] wants to merge 6 commits into
mergify[bot] wants to merge 6 commits into
Conversation
`mergify ci scopes` decodes `git diff` output lossily, so a Latin-1
`critical/caf\xe9.txt` reaches the scope globs as
`critical/caf\u{FFFD}.txt`. The ticket read that as corruption and
leaned toward hard-erroring like `mergify_stack`'s `run_git_capture`.
It is not corruption. The engine scopes a pull request from GitHub's
files API, and that API reports the same path with the same U+FFFD
replacement (checked on a sandbox repository holding a Latin-1 and a
Shift-JIS name). The lossy decode is therefore the name the engine
matches. An error would fail CI on a pull request the engine scopes
fine, and no pattern in the UTF-8 YAML config can spell the raw bytes.
Keep the decode, say why in the doc comment that used to describe it
as a known defect, and pin both probed names in a test so a later
switch to strict decoding fails loudly. The test helpers now also drop
GIT_INDEX_FILE and friends, since the new one writes the index
directly.
What still differs on such paths, and on any non-ASCII path, is glob
semantics: globset's `?` and `[...]` match bytes, the engine's match
characters, so `caf?.txt` misses `caf\u{FFFD}.txt` here and hits it
there. That is MRGFY-10066; matching.rs no longer claims exact parity.
Fixes MRGFY-8289
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Change-Id: I37852b3d50345f42b6dfe8cca6e1b36c8858a3fb
`mergify ci scopes --base origin/main --head HEAD` is the invocation the mergify-ci skill documents. Under `actions/checkout`'s default `fetch-depth: 1` it failed the step with a git error instead of emitting scopes, for two reasons: - The fetch asked the remote for `origin/main`, a name only a clone knows: "fatal: couldn't find remote ref origin/main". A leading `origin/` (or `remotes/origin/`, `refs/remotes/origin/`) is now stripped from the fetch source; the local ref name is unchanged. `feature/x` is left alone, only the remote we fetch from counts as a prefix. - With that fixed, `--deepen` only deepened `main`. HEAD is never fetched by name, so its depth-1 boundary kept hiding its parents and the loop ended with "cannot find a common ancestor". The `--deepen` rounds now also ask for every commit listed in the clone's `shallow` file, so each boundary moves, HEAD's included. The boundary commits rather than HEAD's SHA: they all came from the remote, while HEAD can be a commit made on top of the checkout, which the remote refuses and which would fail the whole fetch. They join only the `--deepen` rounds, never the first `--depth` one, which would cut a history the checkout already has. Pull request events with a head SHA were not affected: both SHAs are fetched. The other auto-detected references that use `HEAD` as head (the `HEAD^` fallback outside GitHub Actions, a push without `before`) get the boundary deepening too. Fixes MRGFY-8290 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Change-Id: If4ba206ad2a6f84fe06a47ba62c1e9149b95c104
`mergify ci git-refs` and `ci scopes` read a pull request body as the engine's merge queue metadata on the title prefix `merge queue: ` alone. The title is the author's to pick, so a fork's pull request could name its own head as `checking_base_sha`: the diff came out empty, every scope read false, and `source: merge_queue` force-enabled the merge-queue scope, with CI green. `pull_request_target` runs that path too. The engine always opens its drafts from a branch of the base repository, so merge queue metadata is now only read when the pull request's head and base live in the same repository (compared by id). That gates the git note as well as the body: a workflow that checks a fork out as `origin` fetches the fork's note, which the fork's author writes. A fork, a deleted fork's head, or a payload without repository ids falls through to the pull request base, with a warning when the title asked for the body. What this does not close: anyone who can read the repository can open a pull request from a branch someone else pushed there and write its title and body. The code under test is then still a writer's. The other signals the ticket listed do not hold up: the branch prefix is `queue_branch_prefix` and the author is `draft_bot_account`, both configurable. Dropping the body path for the git note only was rejected too: the engine writes the note best effort and swallows push failures, and a clone that cannot fetch notes would lose the merge-queue scope on every draft. Fixes MRGFY-8854 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Change-Id: I19f70a5d13a2672ad13b1a4d66f54d132c3ad32e
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🎉 This pull request has been checked successfully and will be merged soon. 🎉
#1881 is queued for merge on branch main (e265eb5).
Stacked behind 2 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 #1881.
Queued ahead of this batch:
This pull request has been created by Mergify to speculatively check the mergeability of #1881.
You don't need to do anything. Mergify will close this pull request automatically when it is complete.
Required conditions of queue rule
defaultfor merge:github-review-approved[🛡 GitHub branch protection]github-review-approved[🛡 GitHub repository ruleset ruleRequire pull request for default branch]Enforce conventional commit]:title ~= ^(fix|feat|internal|docs|style|refactor|perf|test|build|ci|chore|revert|ui)(?:\(.+\))?!?:👀 Review Requirements]:#approved-reviews-by>=2author = dependabot[bot]author = mergify-ci-botauthor = renovate[bot]📕 PR description]:body ~= (?ms:.{48,})🔎 Reviews]:#changes-requested-reviews-by = 0#review-requested = 0#review-threads-unresolved = 0🤖 Continuous Integration]:check-success=ci-gateRequired conditions to stay in the queue:
base=maingithub-review-approved[🛡 GitHub branch protection]github-review-approved[🛡 GitHub repository ruleset ruleRequire pull request for default branch]label!=manual mergeEnforce conventional commit]:title ~= ^(fix|feat|internal|docs|style|refactor|perf|test|build|ci|chore|revert|ui)(?:\(.+\))?!?:👀 Review Requirements]:#approved-reviews-by>=2author = dependabot[bot]author = mergify-ci-botauthor = renovate[bot]📕 PR description]:body ~= (?ms:.{48,})🔎 Reviews]:#changes-requested-reviews-by = 0#review-requested = 0#review-threads-unresolved = 0🤖 Continuous Integration]:check-success=ci-gate