O GitHub anunciou em 12 de junho uma retomada de enforcement para runners self-hosted do GitHub Actions. A mudança cria uma linha mais rígida para registro e execução de jobs: runners antigos podem deixar de registrar, e runners que não acompanham novas versões podem parar de receber trabalho.
Segundo o GitHub Changelog, a versão 2.329.0 ou posterior é o mínimo para configurar ou registrar um runner na nova plataforma. Para continuar executando workflows, o runner também precisa instalar cada nova versão em até 30 dias da publicação. O GitHub afirma que essa política faz parte da migração para uma arquitetura de Actions mais confiável e disponível.
Em termos práticos, runners self-hosted deixam de ser um componente que pode ficar esquecido em uma VM antiga. Eles passam a exigir inventário, atualização recorrente e validação antes das datas de enforcement.
O que muda para runners self-hosted
O anúncio separa duas exigências. A primeira é de configuração ou registro: versões abaixo de 2.329.0 não conseguem se registrar na nova plataforma. A segunda é de execução: runners precisam acompanhar as versões publicadas dentro da janela de 30 dias para continuar pegando jobs.
Essa distinção evita uma interpretação perigosa. Instalar a versão mínima uma vez não resolve o problema para sempre. A própria página do GitHub afirma que 2.329.0 não é uma versão mínima permanente para executar jobs. Ela é o piso de registro na nova arquitetura; a exigência efetiva de execução anda junto com novas releases.
Para times que usam auto-update, o trabalho principal é garantir que o runner alcance o serviço de atualização. Para times que desativaram auto-update, a atualização vira rotina operacional. Imagens de VM, containers, scripts de provisionamento e templates antigos precisam acompanhar a política.
Brownouts viram ensaio obrigatório
O GitHub publicou uma agenda de brownouts para ajudar organizações a encontrar runners antigos antes do bloqueio definitivo. Para GitHub Enterprise Cloud with Data Residency, o enforcement completo começa em 31 de julho de 2026. Para GitHub Enterprise Cloud, a data informada é 25 de setembro de 2026.
Brownout não deve ser tratado como instabilidade aleatória. Ele é um teste programado. Se um job deixa de registrar ou executar durante uma janela anunciada, isso aponta para inventário incompleto, imagem antiga ou processo de atualização que não está fechando.
O impacto pode aparecer longe do runner. Um deploy pode não rodar, uma verificação de segurança pode ficar pendente, um release pode travar, ou uma esteira de pacote pode parar no meio do caminho. A falha parece de CI, mas a causa real pode ser manutenção negligenciada de infraestrutura.
Inventário não pode depender da memória
O GitHub sugere usar eventos de audit log para identificar versões de runners no momento de registro. A própria página alerta que esse sinal não é inventário completo de todos os runners conectados. Isso é importante: em frotas maiores, consultar apenas o que aparece recentemente pode deixar máquinas antigas fora do radar.
Um inventário útil precisa juntar fontes. Lista de runners por organização e repositório, logs de registro, imagens de VM, pipelines de provisionamento, grupos de runner e owners de cada ambiente devem apontar para a mesma realidade. Se um runner existe, alguém precisa saber como ele é recriado, atualizado e removido.
Essa prática conversa com a disciplina de ambientes de staging. Atualizar runner sem ambiente de teste pode quebrar build por ferramenta ausente, cache antigo ou diferença de permissão. Testar uma imagem nova antes do enforcement reduz a chance de descobrir incompatibilidade no release.
Como reduzir risco antes da data limite
O primeiro passo é listar todos os runners self-hosted e separar os que usam auto-update dos que dependem de atualização manual. Depois, o time deve revisar scripts de instalação, imagens base, firewall de saída e permissões do serviço. Runner que não consegue baixar update pode estar tecnicamente configurado, mas operacionalmente vulnerável.
O segundo passo é simular falha. Escolha um workflow crítico e confirme se ele roda em runner atualizado. Depois confirme o que acontece quando o runner fica indisponível: há runner alternativo, fila aceitável, rollback de release ou comunicação clara para o time?
O post sobre timeouts e retentativas ajuda a lembrar que dependências de CI também falham em cadeia. Quando o runner para, scripts que esperam job rápido podem tentar de novo, acumular fila e esconder a causa.
Para quem depende de GitHub Actions em produção, a regra é simples: runners self-hosted fazem parte da plataforma de entrega. Eles precisam ter dono, versão observável, rotina de atualização e teste de substituição. Sem isso, uma política anunciada com meses de antecedência vira incidente no dia do enforcement.
