feat(cli): mergify auth login, logout and status - #1806
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:
|
This was referenced Sep 4, 2026
Contributor
Merge Protections🔴 3 of 7 protections blocking · waiting on 👀 reviews and ⛓️ dependency
🔴 ⛓️ Depends-On RequirementsWaiting for
This rule is failing.Requirement based on the presence of
🔴 👀 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. |
The three commands that give a machine a Mergify credential, take it away, and say which one it holds. `login` prints a URL and a code and waits. The credential lands in the OS keychain, or in a `0600` file when the machine has none, and the command says which -- a user who has to reason about where their secret is should not have to guess. `logout` revokes server-side before it deletes locally, because the server's copy is the one that matters and a token whose only trace was the file we just deleted can no longer be revoked from here at all. If the revocation fails the local copy still goes: a `logout` that left the credential in place because the network blinked would have done nothing at all. The command says so, and names where to finish the job. `status` asks the API rather than trusting the disk. A token revoked from the dashboard is still on the machine and still carries a year-away expiry, so a `status` that read only the local copy would report a dead credential as live. Three deliberate calls: - **No `--json`.** The surface is exactly `login|logout|status [--api-url URL]`, which is what the docs are being written against right now. - **No browser is opened.** The device grant exists because the CLI runs where there is no browser to open -- over SSH, in a container -- and a command that only works when there is one would be a different feature. - **A deployment without `GET /v1/user` still works.** Self-hosted installs upgrade on their own schedule, so a 404 there means "cannot name the account", not "login failed" -- `login` stores the credential and `status` reports it, both saying what they could not check. `login` revokes the credential it replaces, and the one it minted but could not store. Neither is reachable from this machine afterwards, and both stay live on the server for a year -- leaking one per login walks the user into the twenty-token cap that only the dashboard can clear. `auth status` exits 8 when there is no usable credential, which is the code every Mergify command has always returned for that condition. The published description of that code said "configuration file", which was never true of a missing token; it now says configuration *or* credentials. The credential is stored but nothing else reads it yet; the next commit puts it in the resolution chain. No message here claims otherwise. Fixes MRGFY-8703 Change-Id: Ib0b7d16696fa41fc733f2d0fa6ef34246ad8eeb9
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
force-pushed
the
devs/sileht/mrgfy-8703-cli-auth-commands/device-authz-grant-client-side--c7a625b9
branch
from
September 4, 2026 23:40
bc88a36 to
048166f
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.
The three commands that give a machine a Mergify credential, take it
away, and say which one it holds.
loginprints a URL and a code and waits. The credential lands in theOS keychain, or in a
0600file when the machine has none, and thecommand says which -- a user who has to reason about where their secret
is should not have to guess.
logoutrevokes server-side before it deletes locally, because theserver's copy is the one that matters and a token whose only trace was
the file we just deleted can no longer be revoked from here at all. If
the revocation fails the local copy still goes: a
logoutthat left thecredential in place because the network blinked would have done nothing
at all. The command says so, and names where to finish the job.
statusasks the API rather than trusting the disk. A token revokedfrom the dashboard is still on the machine and still carries a
year-away expiry, so a
statusthat read only the local copy wouldreport a dead credential as live.
Three deliberate calls:
--json. The surface is exactlylogin|logout|status [--api-url URL], which is what the docs are being written againstright now.
where there is no browser to open -- over SSH, in a container -- and a
command that only works when there is one would be a different
feature.
GET /v1/userstill works. Self-hostedinstalls upgrade on their own schedule, so a 404 there means "cannot
name the account", not "login failed" --
loginstores the credentialand
statusreports it, both saying what they could not check.loginrevokes the credential it replaces, and the one it minted butcould not store. Neither is reachable from this machine afterwards,
and both stay live on the server for a year -- leaking one per login
walks the user into the twenty-token cap that only the dashboard can
clear.
auth statusexits 8 when there is no usable credential, which is thecode every Mergify command has always returned for that condition. The
published description of that code said "configuration file", which was
never true of a missing token; it now says configuration or
credentials.
The credential is stored but nothing else reads it yet; the next commit
puts it in the resolution chain. No message here claims otherwise.
Fixes MRGFY-8703
Depends-On: #1805