Repository navigation
feat: report the GitHub login a credential was signed in for - #10
Conversation
The server records it now — a sign-in mints a credential and remembers whose it was — and this client dropped the field on the floor, so the one question the record exists to answer could not be asked from here. It is not derivable from the name, which is why it is a field. A credential is *addressed* by a lowercased name, because a URL path segment has no uppercase in its alphabet, and *attributed* to the spelling GitHub reports. The fold is the half that is already in `name`; this is the half that is not. Optional for `shared`'s reason and read the same way: a deployment predating sign-in omits the key, and nil means "this server does not say" rather than "nobody". The decode test covers the absent key as well as an explicit null, because the absent one is the case that would break `auth status` against every older server if it were ever made required — which is the state the deployment is actually in today. Shown only when there is one. A column of dashes on every deployment that has not adopted sign-in teaches an operator to stop reading the column, and `client` already carries the name. The JSON keeps the existing convention for an optional the server may not answer: absent, the way `expiresAt` is. Co-Authored-By: Claude Opus 5 <[email protected]>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Free Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/settings/billing. Comment |
The server records it now — a sign-in mints a credential and remembers whose it was — and this client dropped the field on the floor, so the one question that record exists to answer could not be asked from here.
It is not derivable from the name, which is why it is a field rather than something computed. A credential is addressed by a lowercased name, because a URL path segment has no uppercase in its alphabet, and attributed to the spelling GitHub reports. The fold is the half already carried by
name; this is the half that is not.Optional for
shared's reason and read the same way: a deployment predating sign-in omits the key, and nil means "this server does not say" rather than "nobody". The decode test covers the absent key as well as an explicit null, because the absent one is what would breakauth statusagainst every older server if it were ever made required — and that is the state the deployment is actually in today.Shown only when there is one. A column of dashes on every deployment that has not adopted sign-in teaches an operator to stop reading the column, and
clientalready carries the name. The JSON keeps the existing convention for an optional the server may not answer: absent, the wayexpiresAtalready is in both payloads.This does not implement GitHub sign-in itself.
POST /auth/github/exchangeexists on the server; whether the CLI should speak it is a separate decision, andstele auth loginis unchanged.Checks
swift test— 170 tests in 18 suites, all passing.swift build -c releaseclean, no warnings.Verified against the live deployment, which predates the field:
auth statusandauth status --jsonare byte-for-byte what they were — no row, no key, nothing broken. The present case was verified by driving the binary against a stand-in server answering three rows — a login whose case differs from its name, an explicit null, and the key absent entirely — which renders as aGITHUBcolumn with—for the two that have none, and carries the login through--json.🤖 Generated with Claude Code