Depois do push, o Gitea criou `ci.yml #3` e `runner-check.yml #4`, ambos em
Waiting com a mesma mensagem de runner ausente. Com o `ci.yml #2` anterior, são
três runs enfileirados esperando o runner — nenhum precisa ser republicado.
Duas correções de expectativa que valem registro:
O `concurrency` que eu declarei para evitar fila não tem efeito nesta versão: o
run 667 deveria ter cancelado o 666, do mesmo grupo, e não cancelou. A fila vai
crescer a cada push até existir runner. Fica documentado para ninguém contar
com um cancelamento que não acontece.
A barra lateral de Workflows mostra apenas `ci.yml` porque lista o que existe
na branch padrão, onde `runner-check.yml` ainda não está. Isso não impediu o
run de ser criado a partir de `homologacao`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
O push para o Gitea criou o run, mas ele ficou em Waiting: a mensagem da
instância é "No matching online runner with label: ubuntu-latest". A falha é na
atribuição do job, não no enfileiramento — o gatilho funcionou e a branch está
contemplada. O endpoint /actions/tasks devolvia lista vazia porque lista tasks
aceitas por runner, não runs criados, e foi isso que confundiu a leitura.
Com o diagnóstico fechado, duas coisas importam antes de um runner existir.
Primeira: este repositório é público e o CI dispara em pull_request. Sem
guarda, um fork traria código de terceiro para rodar na máquina do runner, com
Docker à disposição. Os três jobs do ci.yml e o runner-check passam a exigir
que o PR venha da própria origem; push continua rodando normalmente. Também
entram `permissions: contents: read` e `concurrency` por ref, para não
acumular fila de runs esperando runner.
Segunda: `runner-check` é o primeiro workflow a rodar quando o runner subir.
Não faz checkout, não instala dependência, não usa segredo e não toca rede
externa. Só confirma a ligação e inventaria node, npm, docker, psql e python3
— o job `services` precisa de psql e a jornada assíncrona precisa de python3,
e é melhor descobrir isso num workflow de dez segundos.
A documentação registra a evidência (runs 666 em Waiting e 584 cancelado),
recomenda act_runner 0.6.1-dind-rootless com escopo de repositório, e explica
por que Docker-in-Docker em vez do socket do host: num repositório público,
montar o socket entregaria o Docker da máquina ao workflow. Fica registrado
também que os ambientes de aprovação manual do deploy são conceito do GitHub e
não têm equivalente no Gitea.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
