Job pods only need the vault-audience projected token to log in; the
default automounted ServiceAccount token hands them the repospawner
Role's k8s API access that no job subcommand uses.
Four issues from the review of the initial repospawner service, none of
which change the shape of a request or the file terraform-git receives.
- Encode status checks as one --check flag per context on the
server-to-job hop, so a separator inside a context can no longer turn
one context into several; ban commas (and cap lengths) in Validate as
well, since a real context never holds one.
- Fail a merged request that has waited five minutes for a Woodpecker
token that vanished after acceptance, surfacing "woodpecker token
unavailable" through the API, instead of warning in the log forever
from enabling-ci. Advance now leaves a terminal request alone so the
failure sticks.
- Hold a per-name lock from the duplicate checks through the store write,
so two concurrent submissions of one name cannot both be accepted.
- Cap the description at 500 characters and the status checks at 20
contexts of 100 characters each, and mirror the first two caps in the
form.
repospawner turns JSON new-repo requests into terraform-git pull requests
via kubernetes Jobs, follows those PRs to merge and optionally activates
the repository in Woodpecker.
benvin
unkin-agent
gitadmin