feat(core): use the stored credential, deprecate GITHUB_TOKEN - #1807
Conversation
sileht
had a problem deploying
to
func-tests-live
September 4, 2026 23:20 — with 
GitHub Actions
Failure
GitHub Actions
Failure
This was referenced Sep 4, 2026
Member
Author
|
This pull request is part of a Mergify stack:
|
Contributor
Merge Protections🔴 4 of 7 protections blocking · waiting on 👀 reviews, 🤖 CI and ⛓️ dependency
🔴 ⛓️ Depends-On RequirementsWaiting for
This rule is failing.Requirement based on the presence of
🔴 🤖 Continuous IntegrationWaiting for
This rule is failing.
🔴 👀 Review RequirementsWaiting for
This rule is failing.
🔴 🔎 ReviewsWaiting for
This rule is failing.
Show 3 satisfied protections🟢 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. |
`mergify auth login` stored a credential that nothing read. Now the
Mergify API chain reads it:
--token -> MERGIFY_TOKEN -> the stored credential -> GITHUB_TOKEN -> gh auth token
The stored credential sits above the two GitHub fallbacks because a
`GITHUB_TOKEN` left in a shell must not silently override a login the
user performed, and below `--token` and `MERGIFY_TOKEN` so a CI job that
sets one keeps working unchanged. Neither of those two warns. The last
two do, once per process on stderr -- `ci junit-process` uploads a batch
per file, and a warning repeated per API call would bury the output it
is warning about.
`stack` is untouched. It sends GitHub the same chain it sent before,
warns about nothing, and never sees a Mergify-issued token: a GitHub
token is the only kind api.github.com accepts, so deprecating it there
would be nonsense.
`mergify ci` is the other exception, and the reason the resolver takes
an `Audience`. Those routes are `enable_auth_methods("ci_application_key")`
server-side and refuse a user credential by design, because a CI runner
holds an organization key rather than somebody's personal login. So they
never get the stored credential -- offering one would replace a legible
"set MERGIFY_TOKEN" failure with an authentication error -- and both
their deprecation warning and their no-credential error name an
application key instead of `mergify auth login`, which would be a dead
end there. `tests`, `queue`, `freeze`, `events` and `config simulate` do
accept a user credential and get the full chain.
Two smaller consequences:
- `CommandContext::resolve` now resolves the API URL before the token,
because the credential is stored per API URL.
- `auth login` and `auth status` both say when `MERGIFY_TOKEN` is set.
Without that line "logged in" answers a question the user did not
ask: what commands actually send is the environment variable. Both
belong here rather than with the commands themselves, because the
sentence only becomes true once this commit makes something read the
stored credential -- and `login` is the moment somebody is watching,
which `status` is not.
A machine with no configuration directory, or a store that cannot be
read, is a step of the chain that does not apply rather than a refusal
to authenticate -- both fall through with a debug line.
README, the five skills and the ten `--token` help strings that
documented the old chain are updated in the same commit: a user who
sees the deprecation warning and runs `mergify queue --help` to check
must not be told GITHUB_TOKEN is fine and the stored credential does
not exist.
Fixes MRGFY-8703
Change-Id: Ica8900657087d82b92025ad80334e4e0da7862dc
sileht
force-pushed
the
devs/sileht/mrgfy-8703-cli-auth-commands/use-stored-credential-deprecate-github-token--ca890065
branch
from
September 4, 2026 23:40
b78ede8 to
320f6ae
Compare
sileht
force-pushed
the
devs/sileht/mrgfy-8703-cli-auth-commands/mergify-auth-login-logout-status--b0b7d166
branch
from
September 4, 2026 23:40
58321f1 to
4b9647a
Compare
sileht
had a problem deploying
to
func-tests-live
September 4, 2026 23:40 — with
GitHub Actions
Error
GitHub Actions
Error
sileht
had a problem deploying
to
func-tests-live
September 4, 2026 23:40 — with
GitHub Actions
Failure
GitHub Actions
Failure
Member
Author
Revision history
|
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.
mergify auth loginstored a credential that nothing read. Now theMergify API chain reads it:
The stored credential sits above the two GitHub fallbacks because a
GITHUB_TOKENleft in a shell must not silently override a login theuser performed, and below
--tokenandMERGIFY_TOKENso a CI job thatsets one keeps working unchanged. Neither of those two warns. The last
two do, once per process on stderr --
ci junit-processuploads a batchper file, and a warning repeated per API call would bury the output it
is warning about.
stackis untouched. It sends GitHub the same chain it sent before,warns about nothing, and never sees a Mergify-issued token: a GitHub
token is the only kind api.github.com accepts, so deprecating it there
would be nonsense.
mergify ciis the other exception, and the reason the resolver takesan
Audience. Those routes areenable_auth_methods("ci_application_key")server-side and refuse a user credential by design, because a CI runner
holds an organization key rather than somebody's personal login. So they
never get the stored credential -- offering one would replace a legible
"set MERGIFY_TOKEN" failure with an authentication error -- and both
their deprecation warning and their no-credential error name an
application key instead of
mergify auth login, which would be a deadend there.
tests,queue,freeze,eventsandconfig simulatedoaccept a user credential and get the full chain.
Two smaller consequences:
CommandContext::resolvenow resolves the API URL before the token,because the credential is stored per API URL.
auth loginandauth statusboth say whenMERGIFY_TOKENis set.Without that line "logged in" answers a question the user did not
ask: what commands actually send is the environment variable. Both
belong here rather than with the commands themselves, because the
sentence only becomes true once this commit makes something read the
stored credential -- and
loginis the moment somebody is watching,which
statusis not.A machine with no configuration directory, or a store that cannot be
read, is a step of the chain that does not apply rather than a refusal
to authenticate -- both fall through with a debug line.
README, the five skills and the ten
--tokenhelp strings thatdocumented the old chain are updated in the same commit: a user who
sees the deprecation warning and runs
mergify queue --helpto checkmust not be told GITHUB_TOKEN is fine and the stored credential does
not exist.
Fixes MRGFY-8703
Depends-On: #1806