From 550933eef6626c8be4f905dba11370ed235ae9ef Mon Sep 17 00:00:00 2001 From: Julien Danjou Date: Mon, 7 Sep 2026 16:16:58 +0200 Subject: [PATCH 1/3] docs(workflow): depends-on spans a repository owner, not an organization MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Pull Request Dependencies section said a `Depends-On:` header could point at "other repositories with Mergify installed within your organization". The constraint is the same repository *owner*, which may be a user account rather than an organization. A reference to another owner is rendered with a "depends-on conditions must have the same repository owner" warning and never satisfies. The section was also silent on what happens to a reference Mergify cannot resolve — another owner, a repository without Mergify, or a pull request that does not exist. None of those ever reach the `depends-on` attribute, so the condition stays unsatisfied and blocks the merge rather than being skipped, which is the behaviour a reader most needs to be told about. This brings the page in line with the same rules already documented for the `depends-on` merge protection in /merge-protections/builtin, which was corrected and left this page behind. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_019V4gXwb2UucysW4xmB7bAw Change-Id: I790b2c0c6e38ed5eff9ac587378765c72939f264 --- src/content/docs/workflow/actions/merge.mdx | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/src/content/docs/workflow/actions/merge.mdx b/src/content/docs/workflow/actions/merge.mdx index a7fd597ec6..f602c02085 100644 --- a/src/content/docs/workflow/actions/merge.mdx +++ b/src/content/docs/workflow/actions/merge.mdx @@ -43,10 +43,14 @@ known incompatibilities, and how to configure bypass actors, see ## Pull Request Dependencies -You can specify dependencies between pull requests from the same repository, -or from other repositories with Mergify installed within your organization. -Mergify waits for the linked pull requests to be merged before merging any pull -request with a `Depends-On:` header. +You can specify dependencies between pull requests from the same repository, or +from another repository that has Mergify installed and belongs to the same +repository owner, whether that owner is a user or an organization. Mergify waits +for the linked pull requests to be merged before merging any pull request with a +`Depends-On:` header. A reference Mergify cannot resolve blocks the merge rather +than waiting on it, and it stays blocked until you fix the reference. That +includes a reference pointing at another owner's repository, at a repository +without Mergify, or at a pull request that does not exist. To use this feature, add the `Depends-On:` header to the body of your pull request: From 00e4c2f9fad9b450baf5e4fbcc8fb4a926842196 Mon Sep 17 00:00:00 2001 From: Julien Danjou Date: Mon, 7 Sep 2026 16:17:28 +0200 Subject: [PATCH 2/3] docs(workflow): the fork rebase deprecation is not limited to bot_account MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The caution scoped the deprecation to the `rebase` action "with `bot_account`" on fork pull requests. Rebasing always impersonates a GitHub user: when `bot_account` is unset Mergify falls back to the pull request author (or the command sender), and refuses to run when neither resolves. The deprecation notice is posted on any fork rebase, so a reader whose configuration sets no `bot_account` read the caution as not applying to them when it does — the one group the callout most needed to reach. The page's only example was also built on `autosquash`, which the schema marks deprecated, so the single worked example on the page taught the option we are steering people away from. Replaced with a plain label-triggered rebase, matching the "Squash on Label" example on the squash page. Nothing is lost by dropping `autosquash` from the example: the Parameters table still renders its `deprecated` badge from the schema, and Rebase Requirements still documents its effect on the `#commits > 1` disjunct. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_019V4gXwb2UucysW4xmB7bAw Change-Id: Ibf1f715b72dbd21e819305a61b27555cf62874c7 --- src/content/docs/workflow/actions/rebase.mdx | 23 ++++++++------------ 1 file changed, 9 insertions(+), 14 deletions(-) diff --git a/src/content/docs/workflow/actions/rebase.mdx b/src/content/docs/workflow/actions/rebase.mdx index 8081f3f825..21743e67c2 100644 --- a/src/content/docs/workflow/actions/rebase.mdx +++ b/src/content/docs/workflow/actions/rebase.mdx @@ -17,10 +17,12 @@ up-to-date with the latest changes from the base branch. ::: :::caution - Support for the `rebase` action with `bot_account` on fork pull requests is - **deprecated** and will be removed in a future release. If you use this - configuration on - repositories that receive PRs from forks, switch to the + Support for rebasing pull requests that come from a fork is **deprecated** + and will be removed in a future release. This is not limited to + configurations that set `bot_account`: rebasing always impersonates a GitHub + user, and when `bot_account` is unset Mergify falls back to the sender of the + `rebase` command, or to the pull request author when a rule triggered the + rebase. If your repository receives pull requests from forks, switch to the [`update` action](/workflow/actions/update) instead. ::: @@ -40,22 +42,15 @@ commit (`#commits > 1`) is a third way to satisfy that either/or requirement. ## Examples -### Autosquash Fixup Commits +### Rebase on Label -:::caution - The `autosquash` option is **deprecated** and will be removed in a future - release. Avoid relying on it in new configurations. -::: - -Rebase a pull request and fold in any `fixup!`, `squash!`, or `amend!` commits -once it is ready to merge. +Rebase a pull request when it gets the `ready-to-merge` label. ```yaml pull_request_rules: - - name: autosquash fixup commits + - name: rebase when ready to merge conditions: - label = ready-to-merge actions: rebase: - autosquash: true ``` From 8fcbd1c5633dd35283cd911fc2726cbff6220210 Mon Sep 17 00:00:00 2001 From: Julien Danjou Date: Mon, 7 Sep 2026 16:23:36 +0200 Subject: [PATCH 3/3] docs(workflow): document when the review action actually posts The page documented the parameters and nothing about when a review is posted, which is where the surprises are. Four behaviours are load-bearing and were undocumented: - A review whose type and body match one Mergify already posted is skipped, unless it has posted the opposite type since. So a rule that re-approves on every push posts once, not once per push. - That comparison is per account, so changing `bot_account` re-posts an otherwise identical review under the new one. - On a merged pull request only `COMMENT` is posted; `APPROVE` and `REQUEST_CHANGES` are ignored and reported as a success, so a green check is not proof the review landed. - A `REQUEST_CHANGES` or `COMMENT` with no `message` is posted with a generated default body rather than an empty one. This is the last of the three corrections Mergifyio/ci-bot#442 collects; the other two are the commits below it in this stack, so the issue closes once the whole stack has landed. Fixes Mergifyio/ci-bot#442 Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_019V4gXwb2UucysW4xmB7bAw Change-Id: Ieb0af482a6b6c0934a9322c3e9d0b2c0fe005479 --- src/content/docs/workflow/actions/review.mdx | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/src/content/docs/workflow/actions/review.mdx b/src/content/docs/workflow/actions/review.mdx index 43cb3adf07..69e8928ce2 100644 --- a/src/content/docs/workflow/actions/review.mdx +++ b/src/content/docs/workflow/actions/review.mdx @@ -10,6 +10,25 @@ This can be particularly useful in situations where you want to automatically approve pull requests that meet certain criteria, or to request changes on a pull request when a particular check fails. +## How Reviews Are Posted + +Mergify applies these rules when it posts a review: + +- Mergify skips a review whose type and body already match one it posted on the + pull request. It posts the review again if it has posted the opposite type + since: an `APPROVE` after a `REQUEST_CHANGES`, or the reverse. + +- That comparison only covers reviews posted under the same account, so + changing `bot_account` makes Mergify post an otherwise identical review again + under the new one. + +- On a merged pull request, only `COMMENT` is posted. `APPROVE` and + `REQUEST_CHANGES` are ignored, and the action still reports a success — a + green check there is not proof that a review was posted. + +- A `REQUEST_CHANGES` or `COMMENT` review with no `message` is posted with a + default body. Set `message` to choose the wording yourself. + ## Parameters