Resumo

  • O GitHub Actions pode iniciar um fluxo workflow_run quando outro fluxo é solicitado ou concluído, e o GitHub documenta que o fluxo posterior pode ter segredos e tokens de escrita que o anterior não possuía.
  • Essa ligação não é um veredito sobre a confiança do artefato: condição de conclusão, filtro de ramo, checkout, seleção e tratamento do artefato e privilégios efetivos continuam sendo decisões distintas.
  • Uma afirmação auditável reúne o run e a revisão anteriores, a configuração e as condições avaliadas do gatilho posterior, o artefato e checkout exatos, o contexto de privilégio, a decisão posterior e uma observação delimitada do alvo.

Dizer que a publicação « rodou depois da validação » pode resumir uma arquitetura, mas não forma uma cadeia de custódia completa. O GitHub Actions permite que um fluxo escute o evento workflow_run de outro fluxo quando este é solicitado ou termina. O GitHub também informa que o fluxo disparado pode acessar segredos e tokens de escrita ainda que o fluxo anterior não pudesse. A separação pode ser prudente: um trabalho de entrada com menos privilégios produz um candidato, enquanto uma etapa seguinte, mais controlada, decide o que fazer com ele. Mas o desenho também cria uma fronteira de privilégio. O nome do run anterior não revela o que atravessou essa fronteira.

A primeira separação é entre concluir e ser aceito. O GitHub explica que um run de workflow_run é executado independentemente da conclusão do fluxo anterior, a menos que o fluxo posterior inclua uma condição explícita, como github.event.workflow_run.conclusion == 'success'. Assim, a conclusão do run anterior não prova que os controles foram bem-sucedidos nem que o job posterior avaliou a condição pretendida. O nome de um fluxo em um evento não é a revisão do arquivo que o escuta, nem o conteúdo do evento recebido, nem a expressão que autorizou a etapa privilegiada.

Os filtros de ramo têm a mesma fronteira. O GitHub documenta que filtros de ramo de workflow_run se aplicam ao ramo do fluxo disparador e que padrões de inclusão e exclusão obedecem a uma ordem. Uma regra declarada em branches pode mostrar intenção de política. Ela não prova que um artefato veio do commit esperado, que o checkout posterior resolveu a mesma revisão ou que a frase « o ramo de lançamento passou » descreve a referência efetivamente avaliada. Quando essa afirmação precisar ser examinada, o identificador do run anterior, a ação do evento, o ramo e SHA de cabeça, a identidade do fluxo e o contexto de repetição devem ser guardados juntos.

Depois vem o artefato. A documentação de eventos do GitHub mostra que um fluxo posterior pode recuperar artefatos associados ao run que o disparou. Isso é uma rota de acesso, não um certificado de qualidade. Um artefato pode estar corretamente associado a um run e ainda ser a entrada lógica errada para uma ação posterior. O fluxo pode escolher outro nome, baixar um conjunto em vez de um objeto, descompactá-lo em outro ambiente, usar outro checkout ou entregá-lo a um comando que a validação anterior não examinou.

O registro necessário não é apenas « artefato disponível »: ele relaciona o run de origem, nome ou identificador, tamanho e digest quando disponíveis, instante de recuperação, ref e SHA resolvidos do checkout posterior, programa que o consumiu e condições de isolamento ou não execução sob as quais foi tratado.

A referência de uso seguro do GitHub explica por que essa precisão importa. Ela alerta que workflow_run pode se tornar perigoso quando um fluxo privilegiado faz checkout de conteúdo não confiável de pull request; segredos, permissões de escrita e caches compartilhados podem ampliar aquilo que o fluxo posterior aceita. O alerta não acusa um repositório ou artefato específico. Ele expõe uma estrutura: « o fluxo anterior passou » não mostra o que o fluxo privilegiado aceitou depois nem o que estava autorizado a fazer com isso.

O gatilho também não é um recibo de efeito no alvo. Mesmo um artefato corretamente escolhido pode ser usado apenas para inspeção. Um comando posterior pode ser negado por outra fronteira de permissão, parar antes de chamar o alvo, atuar sobre outro recurso ou terminar enquanto uma observação posterior revela outra condição operacional. Inversamente, uma conclusão anterior desfavorável pode constar no evento enquanto uma condição posterior impede toda ação privilegiada. Evento, condição, tratamento do artefato, decisão do comando e estado observado são pontos diferentes.

A resposta prática é um recibo posterior delimitado. Guarde o nome e identificador do fluxo anterior, ação do evento, ramo e SHA de cabeça, conclusão, tentativa ou repetição e uma referência estável à sua definição. Guarde a revisão da definição posterior, o seletor workflow_run, os filtros de ramo e o resultado da condição que permitiu ou bloqueou o job consequente. Guarde especificações de checkout e SHAs resolvidos. Para cada artefato usado, guarde a associação de origem, nome ou identificador, digest disponível, contexto de recuperação e caminho de tratamento. Guarde o contexto efetivo de permissões de GITHUB_TOKEN, disponibilidade de segredos e limites relevantes de cache ou ambiente sem revelar valores sensíveis. Por fim, una o resultado da operação posterior a uma observação do alvo feita em momento separado. Segredos podem ser protegidos; vínculos que nunca foram registrados não podem ser reconstituídos depois.

Essa disciplina não afirma que o pipeline inteiro é « confiável ». Ela indica o que o evento conectou, o que o fluxo posterior decidiu, o que consumiu, qual privilégio detinha e o que foi observado. Um workflow_run pode ser uma fronteira de controle útil. Não deve virar um certificado implícito para artefato, decisão privilegiada e efeito que ele não registrou.

Fontes

  1. GitHub Docs — Events that trigger workflows
  2. GitHub Docs — Secure use reference
  3. GitHub Docs — Triggering a workflow