Lockfiles do Actions chegam a GA: o que um sinal verde comprova
Uma PR pode manter a mesma versão em uses enquanto o código por trás muda. Tags podem apontar para outro commit. O GitHub anunciou a disponibilidade geral dos lockfiles em 28 de outubro. Depois da prévia, vale entender qual evidência cada verificação oferece.
Referências legíveis e commits registrados
.github/workflows/actions.lock relaciona referências de actions aos commits executados. É gerado com gh actions-lock e está disponível em Free, Team e GitHub Enterprise Cloud, inclusive com residência de dados. É possível adotar por workflow. Revise o arquivo gerado junto das mudanças do workflow, sem montá-lo manualmente.
Num exemplo fictício, demo/build@v1 aponta primeiro para A e depois para B. Resolver só a referência pode selecionar outro código na próxima execução; o lockfile conserva o commit registrado. A ilustração não representa um teste real. Um commit que deixe de ser alcançável pela tag ou branch registrada pode ser rejeitado na execução.
O que a verificação off-line estabelece?
gh actions-lock --verify-local verifica a cobertura sem rede: se referências uses têm entradas. É útil antes do commit, mas não comprova procedência. gh actions-lock --verify faz essa verificação on-line, e o runner a repete no início do job. Dois resultados verdes têm significados diferentes.
Se outra PR acrescentar uma action sem atualizar o lockfile, a cobertura local pode detectar a entrada ausente. Ter todas as entradas não prova procedência nem segurança do código. A segunda ilustração resume a documentação; não instalamos nem executamos a CLI para este artigo.
Workflows reutilizáveis cruzam outro limite
Dependências transitivas de actions são cobertas, mas chamadas por jobs.<job_id>.uses não são fixadas pelo lockfile. Use o SHA completo do commit nessas chamadas. As actions internas seguem o lockfile do repositório em que o workflow é definido, não o do chamador.
Imagine uma aplicação chamando o deployment de um repositório de plataforma. O actions.lock da aplicação não revela os pins das actions da plataforma. É preciso relacionar o SHA da chamada às dependências dela. Imagem do runner, entradas e secrets continuam separados: fixar uma action não congela todo o ambiente.
Leia os dois arquivos na PR de atualização
Ao atualizar a versão de uma action de um workflow adotado, o Dependabot regenera a entrada correspondente na mesma PR. Assim, versão legível e commit real aparecem juntos. --relock avança referências movidas e grava arquivos; tem função diferente da verificação somente leitura. A revisão do código continua necessária.
Require lockfile permite exigir a adoção, sem apagar limites entre repositórios. Começar por um workflow ajuda a entender geração, revisão e validação on-line. No próximo sinal verde, observe a evidência exata: cobertura de entradas, procedência ou revisão do código escolhido.