docs(agent): github actions scopes: add the token input, correct the event guard - #12750
Open
Conversation
Contributor
Merge Protections🟠 1 of 6 protections blocking · waiting on 🤖 CI
🟠 🤖 Continuous IntegrationWaiting for
Waiting checks:
|
sileht
approved these changes
Sep 9, 2026
sileht
approved these changes
Sep 9, 2026
AlexandreGaubert
approved these changes
Sep 9, 2026
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.
The Monorepo CI workflow on the GitHub Actions page called the
scopesactionwith
action: scopesand nothing else. Detection and job skipping work thatway, but sending the detected scopes back to Mergify does not, and that upload
is the whole reason the same section points readers at Merge Queue Scopes. The
example now passes
token: ${{ secrets.MERGIFY_TOKEN }}, and a short paragraphsays what the token buys and that
wait-jobsneeds none. It also names thescope: the scopes-upload endpoints accept only a key with the
ciscope andreject an
adminone, which matters more than usual here because a readersetting up Terraform on a neighbouring page is told to use an
adminkey. Arepository whose pull requests come from Dependabot needs the secret in its
Dependabot secrets too, so that is noted as well. This matches the Buildkite
page, which has explained the equivalent for its plugin all along.
The caution above the example claimed the action "requires a pull request
context" and that a
pushtrigger would cause failures. It does not: on apull_requestevent the action works out the base and head to diff on its own,and on any other event there is simply nothing to derive them from, which is
what the
baseinput is for. Guarding the job withif: github.event_name == 'pull_request'is still one valid answer, so itstays, but it is now one of two rather than a workaround for a failure that does
not happen. The caution also notes that the upload is a no-op outside a pull
request, which is why passing
baseon a push is a supported thing to do ratherthan a half-configured one.
Evidence: the action's declared inputs, a production deployment workflow that
runs
action: scopesonpushwith an explicitbase, the security scheme thescopes endpoints declare in the API schema, and the CLI reference for the
command the action wraps, which documents the no-op exit.