# Repositório em qualquer servidor git

A partir da v2.162.0, o runner busca o código de qualquer servidor git, não só do github.com. O GitHub continua sendo o padrão: owner/name sem host significa GitHub, e nada muda nas apps já registradas.

# Formas aceitas no `--repo`

Grupos aninhados ficam inteiros (grupo/sub/projeto). http:// vale como https://.

runner add --repo https://gitlab.com/grupo/sub/projeto.git --branch dist --ckey v2

# Provedor

O provedor é inferido pelo host:

Para servidor próprio, informe o provedor:

runner add --repo https://git.exemplo.com/time/app.git --provider gitea --branch dist

Valores: github, gitlab, bitbucket, gitea, forgejo, azure e generic. --provider github só vale para github.com. Para GitHub Enterprise, use --provider generic por enquanto.

GitHub e, a partir da v2.192.0, GitLab têm driver próprio. Os demais provedores funcionam como git genérico:

• clone, fetch, detecção de commit novo e push do cofre: completos;
• arquivo de versão (version.source: file): lido pelo git, sem API.

# GitLab

Vale para gitlab.com e para GitLab self-managed. No self-managed, informe o provedor:

runner add --repo https://git.exemplo.com/time/app.git --provider gitlab --branch dist --ckey v2

Porta e caminho base (https://git.exemplo.com:8443/gitlab/time/app.git) são preservados.

O token precisa de dois escopos:

Prefira um token de projeto (Settings → Access tokens do projeto), com papel Developer e só esses escopos. Escopos amplos barram o cadastro sem --allow-broad-token: api, sudo, admin_mode, create_runner, manage_runner e k8s_proxy. read_api, write_registry e read_user só geram aviso.

O arquivo de versão é lido pela API v4 do GitLab. Se a API recusar o token, o runner lê pelo git. Repositório por SSH lê sempre pelo git.

# Gitea e Forgejo

Gitea e Forgejo usam o mesmo driver e são sempre servidor próprio. Informe o provedor:

runner add --repo https://git.exemplo.com/time/app.git --provider gitea --branch dist --ckey v2
runner add --repo https://git.exemplo.com/time/app.git --provider forgejo --branch dist --ckey v2

O token de deploy precisa do escopo write:repository. Se a app não usa cofre, read:repository basta.

O arquivo de versão é lido pela API do servidor. Se a API recusar o token, o runner lê pelo git.

Esses servidores não informam os escopos do próprio token. Por isso o runner tokens test e o tokens audit provam a validade e a escrita pelo git e mostram scopes_auditaveis: false.

# Bitbucket Cloud

Vale para bitbucket.org, reconhecido pelo host (v2.198.0+):

runner add --repo https://bitbucket.org/meu-workspace/app.git --branch dist --ckey v2

Use um access token de repositório (Repository settings → Access tokens) com as permissões repository e repository:write. Se a app não usa cofre, repository basta. Um API token da conta Atlassian também serve, com read:repository:bitbucket e write:repository:bitbucket. Nos dois casos o runner clona com o usuário x-token-auth, então não informe usuário.

O arquivo de versão é lido pela API 2.0 do Bitbucket. Se a API recusar o token, se a ref tiver / (release/1.0) ou se o caminho for um diretório, o runner lê pelo git.

O Bitbucket não informa os escopos do próprio token. Por isso o runner tokens test e o tokens audit provam a validade e a escrita pelo git e mostram scopes_auditaveis: false.

O Bitbucket Data Center (servidor próprio) funciona pelo driver genérico.

# Credencial

# HTTPS

Passe o token como hoje:

printf %s "$TOKEN" | runner tokens set minha-app

Se você colar a URL com o token (https://usuario:TOKEN@host/...), o runner tira o token da URL, guarda cifrado e avisa. Um nome de usuário sozinho na URL (o formato que o Bitbucket e o Azure copiam) é descartado, não vira token.

O token só é entregue ao host do repositório. O GITHUB_TOKEN do ambiente vale só para apps do github.com, e --token-from recusa token de outro host (token_de_outro_host).

# SSH

Repositório por SSH usa a chave do servidor (o root do host, em modo não interativo). Token não é usado e, se informado, é ignorado com aviso. O push do cofre (.runner/secrets.enc) também vai pela chave.

O host do repositório precisa estar no known_hosts do root:

ssh-keyscan -H git.exemplo.com >> /root/.ssh/known_hosts

# Conferir

runner tokens test minha-app --json   # provider, write e scopes_auditaveis
runner snapshot -o json               # provider e repo_url de cada app

O tokens audit confere escopo e validade onde há API de token: github.com e GitLab por https. Nos demais provedores, confere a validade com um git ls-remote.

# Ver também

• Deploy de repositório privado
• runner tokens