Every repo that wants the CI-based agent-run flow (agent-run.yml, dispatch#56/#67/#72 lineage) needs four things set up per-repo before an issue labeled agent/ci-run can actually run:
A write deploy key (AGENT_PR_DEPLOY_KEY) scoped to that repo only
Today none of this is settable through gitea-mcp. It has to be done by hand in the Gitea web UI for every new project repo, which breaks the goal of driving project setup end-to-end from a chat/voice session (see spatial-agent-app#1 onboarding — had to stop and hand this off).
repo_deploy_key_create (owner, repo, title, public_key, read_only) — register a deploy key on a repo.
Possibly a higher-level convenience tool, e.g. repo_enable_agent_run, that does the whole bundle in one call for a repo that already has agent-run.yml: sets the three shared secrets (likely read from the same source the cluster's dispatch-secrets ExternalSecret already uses, so the LiteLLM/dispatch-bot credentials aren't re-entered by hand each time) and generates + registers a fresh per-repo deploy keypair, returning only what must leave the server (nothing — the private key should stay server-side if it generates it).
Constraints / things to get right
Per-repo deploy key must stay scoped to that one repo (mirrors AGENT_PR_DEPLOY_KEY pattern already used by cobalt-dingo — narrower than a PAT on purpose).
DISPATCH_BOT_TOKEN_RO / AGENT_PR_BOT_TOKEN are shared dispatch-bot account tokens, not unique per repo — likely sourced once (e.g. from the same secret store backing k3s/apps/dispatch/externalsecret.yaml) and just attached to each new repo, not regenerated per repo.
Secret values must never be echoed back in a tool result or left in a tool-call transcript.
Should be safe/idempotent to re-run on a repo that already has some of these set (same spirit as create_project_from_template's resume behavior).
Why now
Came up while onboarding mathias/spatial-agent-app for agent-run: repo + template + .dispatch-allow + agent-run.yml could all be done from a chat session, but secrets/deploy key could not, forcing a manual step that defeats the "fully voice/chat-drivable project kickoff" goal.
## Problem
Every repo that wants the CI-based agent-run flow (`agent-run.yml`, dispatch#56/#67/#72 lineage) needs four things set up per-repo before an issue labeled `agent/ci-run` can actually run:
- Repo secret `LITELLM_API_KEY`
- Repo secret `LITELLM_BASE_URL`
- Repo secret `DISPATCH_BOT_TOKEN_RO` (read:repository + read:issue, dispatch-bot account)
- Repo secret `AGENT_PR_BOT_TOKEN` (write:repository, dispatch-bot account)
- A write deploy key (`AGENT_PR_DEPLOY_KEY`) scoped to that repo only
Today none of this is settable through gitea-mcp. It has to be done by hand in the Gitea web UI for every new project repo, which breaks the goal of driving project setup end-to-end from a chat/voice session (see spatial-agent-app#1 onboarding — had to stop and hand this off).
## Proposal
Add MCP tools for:
1. `repo_secret_set` (owner, repo, secret_name, value) — create/update a repo-level Actions secret.
2. `repo_deploy_key_create` (owner, repo, title, public_key, read_only) — register a deploy key on a repo.
Possibly a higher-level convenience tool, e.g. `repo_enable_agent_run`, that does the whole bundle in one call for a repo that already has `agent-run.yml`: sets the three shared secrets (likely read from the same source the cluster's `dispatch-secrets` ExternalSecret already uses, so the LiteLLM/dispatch-bot credentials aren't re-entered by hand each time) and generates + registers a fresh per-repo deploy keypair, returning only what must leave the server (nothing — the private key should stay server-side if it generates it).
## Constraints / things to get right
- Per-repo deploy key must stay scoped to that one repo (mirrors `AGENT_PR_DEPLOY_KEY` pattern already used by cobalt-dingo — narrower than a PAT on purpose).
- `DISPATCH_BOT_TOKEN_RO` / `AGENT_PR_BOT_TOKEN` are shared dispatch-bot account tokens, not unique per repo — likely sourced once (e.g. from the same secret store backing `k3s/apps/dispatch/externalsecret.yaml`) and just attached to each new repo, not regenerated per repo.
- Secret values must never be echoed back in a tool result or left in a tool-call transcript.
- Should be safe/idempotent to re-run on a repo that already has some of these set (same spirit as `create_project_from_template`'s resume behavior).
## Why now
Came up while onboarding `mathias/spatial-agent-app` for agent-run: repo + template + `.dispatch-allow` + `agent-run.yml` could all be done from a chat session, but secrets/deploy key could not, forcing a manual step that defeats the "fully voice/chat-drivable project kickoff" goal.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
Every repo that wants the CI-based agent-run flow (
agent-run.yml, dispatch#56/#67/#72 lineage) needs four things set up per-repo before an issue labeledagent/ci-runcan actually run:LITELLM_API_KEYLITELLM_BASE_URLDISPATCH_BOT_TOKEN_RO(read:repository + read:issue, dispatch-bot account)AGENT_PR_BOT_TOKEN(write:repository, dispatch-bot account)AGENT_PR_DEPLOY_KEY) scoped to that repo onlyToday none of this is settable through gitea-mcp. It has to be done by hand in the Gitea web UI for every new project repo, which breaks the goal of driving project setup end-to-end from a chat/voice session (see spatial-agent-app#1 onboarding — had to stop and hand this off).
Proposal
Add MCP tools for:
repo_secret_set(owner, repo, secret_name, value) — create/update a repo-level Actions secret.repo_deploy_key_create(owner, repo, title, public_key, read_only) — register a deploy key on a repo.Possibly a higher-level convenience tool, e.g.
repo_enable_agent_run, that does the whole bundle in one call for a repo that already hasagent-run.yml: sets the three shared secrets (likely read from the same source the cluster'sdispatch-secretsExternalSecret already uses, so the LiteLLM/dispatch-bot credentials aren't re-entered by hand each time) and generates + registers a fresh per-repo deploy keypair, returning only what must leave the server (nothing — the private key should stay server-side if it generates it).Constraints / things to get right
AGENT_PR_DEPLOY_KEYpattern already used by cobalt-dingo — narrower than a PAT on purpose).DISPATCH_BOT_TOKEN_RO/AGENT_PR_BOT_TOKENare shared dispatch-bot account tokens, not unique per repo — likely sourced once (e.g. from the same secret store backingk3s/apps/dispatch/externalsecret.yaml) and just attached to each new repo, not regenerated per repo.create_project_from_template's resume behavior).Why now
Came up while onboarding
mathias/spatial-agent-appfor agent-run: repo + template +.dispatch-allow+agent-run.ymlcould all be done from a chat session, but secrets/deploy key could not, forcing a manual step that defeats the "fully voice/chat-drivable project kickoff" goal.