# Runner do Gitea (act_runner)

Runner que executa a esteira [`build-api-image.yml`](../workflows/build-api-image.yml).
Sobe em um servidor **separado** do Gitea — o Gitea fica em `192.168.0.41:3001`
e este compose roda na máquina que vai construir as imagens.

## Instalação

```bash
cp .env.example .env
```

Pegue o token de registro no Gitea e cole em `GITEA_RUNNER_REGISTRATION_TOKEN`:

| Escopo do runner | Onde pegar o token |
| --- | --- |
| Só o repositório conectasus | Repo › Settings › Actions › Runners › Create new runner |
| Toda a organização `rkm` | Org › Settings › Actions › Runners |
| Instância inteira | Site Administration › Actions › Runners |

Depois:

```bash
docker compose up -d
docker compose logs -f
```

O runner aparece como online em Settings › Actions › Runners do Gitea. O token de
registro é usado uma única vez; a credencial permanente fica em `./data/.runner`.

## O que o compose faz

| Item | Motivo |
| --- | --- |
| `/var/run/docker.sock` montado | O `act_runner` usa o daemon do host para criar os containers de job **e** repassa o socket para dentro deles. É isso que faz o `docker build` da esteira funcionar. |
| `./data` | Guarda o registro do runner. Apagar essa pasta força novo registro. |
| Label `ubuntu-latest:docker://gitea/runner-images:ubuntu-latest` | Casa com o `runs-on: ubuntu-latest` do workflow. Essa imagem (0,57 GB) já traz `docker`, `git`, `node`, `bash` e `curl` — tudo que a esteira usa. A variante `-full` tem 17,6 GB e não é necessária. |

Como o Gitea está em outro servidor, tudo que aponta para ele é configuração:
`GITEA_INSTANCE_URL` e o token vêm do `.env`, nada fixo no compose. Se as
variáveis obrigatórias faltarem, o `docker compose up` falha na hora com a
mensagem em vez de subir um runner quebrado.

## Pré-requisitos no servidor do runner

**1. Alcançar o Gitea.** O runner e os containers de job precisam falar com
`192.168.0.41:3001` (API do Actions e registry de imagens):

```bash
curl -s http://192.168.0.41:3001/api/v1/version
```

**2. Confiar no registry via HTTP.** O registry não tem TLS, e o `docker push` da
esteira roda no daemon do host (por causa do socket montado). Então a
configuração é do host, não do compose — em `/etc/docker/daemon.json`:

```json
{ "insecure-registries": ["192.168.0.41:3001"] }
```

Se o arquivo já existir, **acrescente ao array** em vez de sobrescrever. Depois:

```bash
systemctl reload docker
docker info | grep -A5 'Insecure Registries'
```

Use `reload`, não `restart`. `insecure-registries` é recarregável por SIGHUP, e
`restart` derruba todos os containers do host quando `live-restore` está
desligado (confira com `docker info --format '{{.LiveRestoreEnabled}}'`).

Sem isso o push falha com `http: server gave HTTP response to HTTPS client`.

**3. Espaço em disco.** Cada build gera uma imagem da API com o `vendor/`
completo. Convém uma limpeza periódica:

```bash
docker image prune -af --filter "until=168h"
```

## Mudando o runner de máquina

O compose não tem nada preso à máquina: o Gitea é alcançado por
`GITEA_INSTANCE_URL`, que vem do `.env`. Para mover o runner basta subir o
compose no servidor novo e registrar de novo.

Na fase inicial de desenvolvimento é natural rodar na própria máquina de dev.
Duas ressalvas quando esse host também roda outros containers:

- Um `restart` do daemon Docker (necessário se você usar `restart` em vez de
  `reload` para o `insecure-registries`) derruba tudo que estiver no host.
- Os builds competem por disco e CPU com os containers já existentes.

Ao migrar para o servidor do Gitea, o registro anterior deve ser removido em
Settings › Actions › Runners, e a pasta `./data` do host antigo descartada.
`GITEA_INSTANCE_URL` pode continuar apontando para o IP — não precisa virar
`localhost`.

## Notas

- Se o Gitea for acessado por hostname em vez de IP e o servidor do runner não
  resolver esse nome, acrescente `extra_hosts` ao serviço no compose.
- Por padrão o runner executa **um job por vez**. Para paralelismo, monte um
  `config.yaml` com `runner.capacity` e aponte `CONFIG_FILE` para ele.
- O socket do Docker montado dá ao runner controle total sobre o daemon do host.
  Use um servidor dedicado a CI, não um que rode containers de produção.