APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Um runner disponível não é necessariamente elegível. A seleção considera labels e grupos autorizados; todas as condições relevantes precisam de corresponder. Começa o diagnóstico de queued pelo pedido efetivo, acesso do repositório, estado do runner e capacidade do conjunto elegível. Evita remover restrições apenas para fazer o job avançar. Essas restrições podem separar redes, identidades e dados de produção. Num runner persistente, o estado deixado por um job pode afetar o seguinte. Executar código externo nesse ambiente requer avaliar o que ele pode ler, alterar e deixar preparado para futuras execuções, incluindo ferramentas, diretórios de trabalho e acesso à rede.
Aplicação guiada
Num deploy fictício de pagamentos, dez runners livres fora do grupo autorizado não resolvem falta de capacidade dentro da fronteira aprovada. O responsável L3 deve identificar se existe erro de seleção ou indisponibilidade real, e o gestor deve avaliar o prazo da janela. Runners efémeros recebem um único job antes do desregisto; a equipa continua responsável pela destruição e preservação externa dos logs. Para imagens alojadas pelo GitHub, declara versões de ferramentas necessárias e regista o ambiente observado: uma label de sistema não congela toda a imagem. No consumo de workflows privados, confirma também as políticas do caller e a partilha do repositório chamado antes de atribuir a falha à infraestrutura.
Grupo correto, label payments ausente: queued pode ser um problema de elegibilidade, não saturação global.
Armadilhas comuns
Online como elegível; label como isolamento; desregisto como disco apagado; imagem alojada como toolchain congelada.
Tópicos relacionados: Eventos, filtros e dependências · Dados, outputs e rede dos services · Reutilização, artifacts e diagnóstico
Mede capacidade dentro da fronteira autorizada e preserva evidência fora dos runners descartáveis.
Referência: Self-hosted and ephemeral runners · GH-200 skills measured January2026;study guide updated2026-02-05