Skip to content

merge queue: checking #1806 on main (251e0f0) - #1822

Closed
mergify[bot] wants to merge 2 commits into
mainfrom
mergify/merge-queue/c2e0dc3d18
Closed

merge queue: checking #1806 on main (251e0f0)#1822
mergify[bot] wants to merge 2 commits into
mainfrom
mergify/merge-queue/c2e0dc3d18

Conversation

@mergify

@mergify mergify Bot commented Sep 10, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

🎉 This pull request has been checked successfully and will be merged soon. 🎉

#1806 is queued for merge on branch main (251e0f0).

This pull request has been created by Mergify to check the mergeability of #1806.
You don't need to do anything. Mergify will close this pull request automatically when it is complete.

Required conditions of queue rule default for merge:

Required conditions to stay in the queue:

---
checking_base_sha: 251e0f08b3cbcb1640169d15fe0fca63c6f529eb
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 1806
    scopes: []
scopes: []
...

sileht and others added 2 commits September 9, 2026 21:04
@sileht
feat(cli): mergify auth login, logout and status
d170ade 
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. When the revocation of the *replaced* one fails, the command
says so out loud rather than in a debug line: that token is the leak
this block exists to prevent, and the user is the only one who can
finish it. The other case stays quiet, since the command is already
returning its own error about a token that never reached the store.

Two ordering rules, both about a grant the user may have approved:

- The store is read **before** the grant is opened, not merely before
  it is spent. A corrupt `credentials.json` read afterwards kills the
  command with the approval page already on screen, and whatever the
  user approves there mints a token nothing stores and nothing
  revokes. `authorize` needs no store, so this costs nothing.
- `logout`'s no-credential branch still asks the store to forget, and
  now reports what a *refused* answer there means. A keychain can deny
  a read and still delete -- macOS deletes an item whose read ACL it
  refuses, since deleting needs no decrypt -- so a credential can be
  removed without ever being read, which is a token this command could
  not ask the server to revoke. The error names the dashboard.

`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
@mergify
Merge of #1806
1ecd787
@mergify
mergify Bot deployed to Mergify Merge Protections September 10, 2026 09:08 Active
@mergify mergify Bot mentioned this pull request Sep 10, 2026
Merged
@mergify
mergify Bot deployed to func-tests-live September 10, 2026 09:08 Active
@mergify mergify Bot closed this Sep 10, 2026
@mergify
mergify Bot deleted the mergify/merge-queue/c2e0dc3d18 branch September 10, 2026 09:15

This branch was successfully deployed

2 active deployments
func-tests-live — 1ecd7871 Deployed Sep 10, 2026 by mergify[bot] via live-tests #1857
Mergify Merge Protections — 1ecd7871 Deployed Sep 10, 2026 by mergify[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@sileht