naudachu
f18a633185
The plugin required `tea`, Gitea's own CLI, for everything that is not an issue: releases, pull requests, milestones, branches, actions, webhooks. That put a second binary, a second set of logins nothing here could see, and 400 lines documenting somebody else's flags outside anything this repository can test. One command over the transport that already existed removes all three. Transport: `post` — the hand-rolled request the SDK cannot express, written for the dependency endpoint — is generalized to an exported `Do`, and `post` is three lines on top of it. Same http.Client, so the same RoundTripper files the body under .kettle/payload/, the same `token …` header authenticates it, and a non-2xx is the same *APIError. It does not paginate, does not reformat the answer, and names no domain concept, so the layering test is untouched. The endpoint rule is `tea api`'s, so an endpoint table written for that tool still works — with one restriction it did not have: a full URL must be on this instance. Every request carries the project's token in a header, and a URL on another host would hand the token to whatever was typed. Command: `kettle api <endpoint>` in a new `api` group, so the generator writes plugins/kettle/skills/api/SKILL.md — group, directory and /kettle:api are one word. No --repo and no --login, for the reason no sync command has them: a cross-repository address is an address, and another instance is KETTLE_URL. `-X DELETE` needs `--yes`; a flag typed on purpose is an operator's decision. Scopes: a token minted for issues carries write:issue and answers 403 on the first request outside issues, naming no scope. Gitea cannot be asked what a token may do — its own token listing needs a password — so `auth add --scopes` records it, `auth list` and `config` show it, and a 403 says which category it is likely to be. Documentation only; nothing is checked against it. skills/use — the tea reference, 239 lines of it — becomes skills/api: what to ask for, which endpoints paginate, and how to write a body. Every mention of `tea` as a requirement is gone from the manifests, the READMEs, the runner and the four other skills; what survives is the back-compat with the old plugin, which is a decision and not a debt. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
121 lines
6.2 KiB
Markdown
121 lines
6.2 KiB
Markdown
# AGENTS.md — internal/config
|
|
|
|
**Two files: what this project is, and who this machine is.** The only package in
|
|
the tree that imports yaml.
|
|
|
|
| file | what is in it |
|
|
|---|---|
|
|
| `config.go` | `Project` and `Logins` (the two files), `Resolve`/`ResolveOutsideAProject`/`Require`, `Resolved` with `Complete` and `Redacted`, the `KETTLE_*` overrides, and the 0600 write |
|
|
|
|
## The split is the whole design
|
|
|
|
```
|
|
<project>/.kettle/config.yaml login: noodles a NAME, never a token
|
|
repo: owner/name
|
|
|
|
~/.config/kettle/logins.yaml logins: [{name, url, user, scopes, token}]
|
|
mode 0600
|
|
```
|
|
|
|
`user` and `scopes` are **documentation and nothing else** — nothing is checked
|
|
against either, and no request is refused because of one. `scopes` is what the
|
|
token was minted with, as Gitea spells it (`write:issue`, `write:repository`),
|
|
and it is written down because the instance will not answer the question:
|
|
`GET /user/tokens` needs basic auth rather than token auth, so a token cannot be
|
|
asked what it may do. What it buys is a 403 that can be read — `kettle auth list`
|
|
and `kettle config` show what was recorded, and an empty list means "nobody wrote
|
|
it down", never "none".
|
|
|
|
**A token in a file inside a working tree ends up in a commit.** Not always, not
|
|
immediately, and not by anyone careless — but a project config is exactly the file
|
|
somebody eventually decides to share, and a secret that has ever been pushed has to
|
|
be rotated. So the project pins a login by **name**, and the name is worth nothing
|
|
on its own, which is what makes it safe to keep in a repository.
|
|
|
|
Which tokens this computer holds is a fact about the computer, the way which issues
|
|
a tree holds is a fact about the tree. `SaveLogins` writes 0600 into a 0700
|
|
directory; nothing else on the machine has any business reading it. `$KETTLE_CONFIG_HOME`
|
|
relocates it — the test suite sets it, so a run can neither read nor overwrite the
|
|
developer's own tokens — and `$XDG_CONFIG_HOME` is honoured too.
|
|
|
|
**Nothing prints a token.** `Redacted` is what a receipt gets; `kettle config` shows
|
|
`(set)`.
|
|
|
|
## Resolution, and why it fails early
|
|
|
|
`Resolve` merges three sources — the project config, the machine's login file, and
|
|
the environment — into `Resolved`, which is everything the transport needs.
|
|
|
|
**Every failure names the file it read and the command that fixes it.**
|
|
"401 Unauthorized" is what happens when this function is allowed to return a
|
|
half-filled struct, and a 401 names nothing an operator can act on.
|
|
|
|
The same discipline splits the two "missing" answers: a missing `config.yaml` is
|
|
`ErrNoConfig`, not an empty config, because "this project has not been told which
|
|
tracker it belongs to" and "it belongs to no tracker" are different answers and only
|
|
one is fixed by running `init`. A missing login file, by contrast, **is** an empty
|
|
list — a machine with no logins yet is an ordinary machine.
|
|
|
|
`Complete` is that assertion on its own, as a method, because the two questions are
|
|
different: `kettle config` wants to **show** a half-filled configuration and
|
|
everything that dials wants to **refuse** one. `Require` is `Resolve` plus
|
|
`Complete`; [`gitea.New`](../gitea/AGENTS.md) and `cmd/release` call `Complete`
|
|
themselves, so a client can never be built from a struct that is missing a field.
|
|
|
|
`ResolveOutsideAProject` is for the one caller that legitimately stands nowhere near
|
|
a project: [`cmd/release`](../../cmd/release/AGENTS.md), run from a fresh clone. The
|
|
marker is gitignored, so a clone has none and a build tool must not create one — and
|
|
with no marker there is nothing to merge, so the **environment is** the
|
|
configuration. A marker that is there is read as always, so the same command run
|
|
from a maintainer's own checkout picks up the login pinned in it. Every other caller
|
|
wants `Resolve`, where "no project" is the answer rather than a state to work
|
|
around: a push that quietly ran against whatever was in the environment would be a
|
|
push into somebody else's repository.
|
|
|
|
`ReadProjectFile` exists for exactly one caller: `kettle init`, which is creating
|
|
the marker `LoadProject` walks for, and on a dry run may not have created it at all.
|
|
|
|
## Overrides
|
|
|
|
| variable | shadows |
|
|
|---|---|
|
|
| `KETTLE_LOGIN` | `login:` in the project config |
|
|
| `KETTLE_REPO` | `repo:` in the project config |
|
|
| `KETTLE_URL` | the login's `url` |
|
|
| `KETTLE_TOKEN` | the login's `token` |
|
|
| `KETTLE_CONFIG_HOME` | the directory holding `logins.yaml` |
|
|
|
|
Each wins over the file it shadows. They exist for CI, for a one-off run against
|
|
another instance, and for anyone who would rather not have a token on disk at all.
|
|
|
|
## Unknown keys are an error
|
|
|
|
Not a silent drop. An older binary reading a newer config would otherwise delete the
|
|
setting it did not recognize the next time it wrote the file — which is a data-loss
|
|
bug that only shows up on the machine running the older build.
|
|
|
|
**The price is that a field added here is a one-way door for the file that holds
|
|
it.** `scopes:` was the first one to prove it: a login file written by a binary
|
|
that has the field cannot be read by one that does not — the older build stops
|
|
with "unknown field" rather than dropping the line. That is acceptable for
|
|
`logins.yaml`, which is machine-local and whose reader is the one binary the
|
|
operator upgrades; it would **not** be acceptable for `config.yaml`, which is
|
|
committed and read by whatever version each machine happens to have. Adding a
|
|
field to the project file means answering that first, out loud, here.
|
|
|
|
## What does not belong here
|
|
|
|
A request, a store path, an issue. This package reads and writes two files and
|
|
answers "who am I and where am I pointed"; [`gitea`](../gitea/AGENTS.md) takes the
|
|
answer and dials, and the paths themselves come from
|
|
[`project`](../project/AGENTS.md).
|
|
|
|
## Keeping this file true
|
|
|
|
- **Scope:** `config.go` — the two files, their fields, the overrides, the file modes.
|
|
- **Update it when** a field is added to either file (both tables above are the
|
|
contract), an override is added or renamed, the location or mode of the login file
|
|
changes, or the unknown-key policy changes.
|
|
- **Do not** move a credential into the project file, and if that ever changes, the
|
|
argument above is what has to be answered first.
|