O GitHub Actions recebeu três mudanças que tornam a automação de entrega mais explícita: uma API para consultar a descontinuação de versões de runners, uma permissão de leitura de alertas de vulnerabilidade e novas propriedades para identificar a origem de jobs em workflows reutilizáveis.1
São alterações menos vistosas que uma nova interface, mas atingem pontos que costumam crescer silenciosamente em uma operação de software. O mesmo pipeline que começou publicando um site pode passar a atender vários repositórios, depender de máquinas próprias e consultar informações de segurança. Nesse cenário, saber o que está executando e com qual autoridade deixa de ser detalhe.
A versão do runner entra no planejamento
A nova API REST informa quando uma versão do runner deixará de aceitar registros e quando perderá suporte para execução. Os campos registration_deprecates_at e runtime_deprecates_at separam esses dois momentos, que podem exigir ações diferentes.1
Para equipes com runners próprios, essa informação permite antecipar a manutenção. Uma máquina pode continuar ligada e aparentemente saudável, mas estar próxima de não conseguir executar novos trabalhos. Consultar o prazo evita descobrir a restrição somente durante uma publicação urgente.
O ganho depende de usar o dado dentro da gestão do parque de execução. Inventário de versões, atualização da imagem e teste dos jobs mais importantes formam uma sequência mais útil do que apenas registrar a data em uma planilha. Também ajudam a distinguir problema de código de problema da infraestrutura que executa o código.
Consultar alertas não exige uma credencial ampla
A permissão vulnerability-alerts permite dar ao GITHUB_TOKEN acesso somente de leitura aos alertas do Dependabot. Ela aceita os valores read e none, oferecendo uma opção mais restrita para workflows que precisam consultar esses dados.1
Uma rotina pode, por exemplo, montar um relatório de dependências vulneráveis sem receber permissão para alterar o repositório. O desenho fica mais claro quando a tarefa de leitura e a tarefa de publicação não compartilham automaticamente a mesma autoridade.
Isso não transforma todo alerta em motivo para bloquear uma entrega. Uma vulnerabilidade em uma ferramenta de desenvolvimento pode ter condições de exploração diferentes de uma falha no serviço exposto ao público. A automação ganha valor ao encaminhar a informação certa, enquanto a política da equipe define gravidade, exposição e prazo de tratamento.
Workflows reutilizáveis passam a mostrar a própria origem
As novas propriedades do contexto job identificam a referência, o commit, o repositório e o caminho do arquivo que define o job. Em workflows reutilizáveis, elas apontam para o workflow chamado, enquanto propriedades equivalentes do contexto github refletem o chamador. O GitHub informa que essa novidade não está disponível no GitHub Enterprise Server.1
Essa distinção é útil quando um repositório central distribui pipelines para várias aplicações. O registro de uma entrega pode indicar não apenas qual código foi publicado, mas qual revisão da rotina de publicação executou o trabalho. Se uma alteração na automação provocar uma regressão, fica mais fácil localizar os projetos afetados.
No mesmo início de mês, o CodeQL 2.26.4 passou a detectar referências mutáveis a workflows reutilizáveis na consulta actions/unpinned-tag. Também refinou verificações de campos do ator conforme o evento que realmente fornece esses dados.2
As duas novidades se encontram em um ponto: compartilhar automação não elimina a necessidade de conhecer sua versão. Uma tag que muda pode levar uma alteração a muitos projetos; uma referência fixa oferece uma revisão identificável, mas ainda exige um processo de atualização. Nenhuma das opções dispensa acompanhar o código que recebe acesso à entrega.
Os ajustes do GitHub não redesenham o CI/CD. Eles tornam mais visíveis dependências que já existiam. Para sistemas que precisam de publicação previsível, essa visibilidade ajuda a transformar um conjunto de arquivos YAML em uma operação que pode ser explicada, mantida e reconstruída.
- GitHub, "GitHub Actions: Early September 2026 updates", 3 set. 2026. ↩
- GitHub, "CodeQL 2.26.4 improves GitHub actions security detections", 3 set. 2026. ↩