docs(conditions): document the qualified form for deployment conditions - #12657
Open
sileht wants to merge 1 commit into
Conversation
`deployment-success` / `deployment-failure` now accept the same `@<github-app-slug>/<environment>` form the `check-*` attributes already do, so a rule can require an environment be deployed by one particular app rather than by whoever posted a deployment status last. That matters because anyone with `deployments: write` on the repository can post a status for any environment name. The reference only covered checks, so the syntax existed with nowhere documenting it for deployments. Related to MRGFY-8824 Change-Id: I7ad4420d7b4c9fa95631b2f1303600180e94b65e
Contributor
Merge Protections🔴 2 of 6 protections blocking · waiting on 👀 reviews
🔴 👀 Review RequirementsWaiting for
This rule is failing.
🔴 🔎 ReviewsWaiting for
This rule is failing.
Show 4 satisfied protections🟢 🤖 Continuous Integration
🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 📕 PR description
🟢 🚦 Auto-queueWhen all merge protections are satisfied, this pull request will be queued automatically. |
There was a problem hiding this comment.
🟢 Approval recommended
The change is a straightforward documentation addition with only a minor structural tweak suggested.
Pull request overview
This PR updates the Mergify conditions reference to document that deployment-success / deployment-failure support the qualified @<github-app-slug>/<environment> syntax (similar to the existing qualified form for check-* conditions), enabling rules to match deployments reported by a specific GitHub App.
Changes:
- Adds a new documentation subsection explaining the qualified deployment condition form.
- Includes an example showing how to pin an environment deployment to a specific app slug.
- Clarifies backward compatibility of the bare (unqualified) deployment condition form.
File summaries
| File | Description |
|---|---|
| src/content/docs/configuration/conditions.mdx | Documents the qualified deployment condition syntax and provides an example + compatibility notes. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| conditions and legacy GitHub commit statuses carry no GitHub App identity | ||
| and remain reachable only via the bare form. | ||
|
|
||
| ### Qualifying Deployments |
jd
approved these changes
Sep 2, 2026
sileht
marked this pull request as ready for review
September 2, 2026 13:29
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
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.
deployment-success/deployment-failurenow accept the same@<github-app-slug>/<environment>form thecheck-*attributes already do,so a rule can require an environment be deployed by one particular app rather
than by whoever posted a deployment status last. That matters because anyone
with
deployments: writeon the repository can post a status for anyenvironment name.
The reference only covered checks, so the syntax existed with nowhere
documenting it for deployments.
Related to MRGFY-8824