Conceito e mecanismo
O workflow tem várias fronteiras de dados. Uma variável local pertence ao processo do shell. Escrever em GITHUB_ENV disponibiliza um valor aos steps seguintes do mesmo job, sem alterar automaticamente o shell que fez a escrita. Para atravessar jobs, um step identificado publica um output, o job mapeia esse resultado e o consumidor usa needs. Valores escalares e ficheiros têm canais diferentes: um digest pode ser um output, enquanto o binário correspondente deve ser transportado como artifact identificado. Nunca transformes outputs ou logs num canal improvisado de credenciais. O contrato deve indicar nome, significado, origem e tratamento de valores em falta.
Aplicação guiada
Num ensaio fictício de reporting, build produz um digest e deploy compara-o com o candidato aprovado antes de promover. Se o valor chega vazio, inspeciona a escrita do step, o seu ID, o mapeamento do job e a referência do consumidor. Não substituas um valor ausente por uma aprovação implícita. Para testes PostgreSQL, identifica onde executa o cliente: dentro do contentor do job, o nome do service permite chegar ao contentor da base de dados; localhost identifica o próprio contentor. Um job diretamente no runner usa o desenho de portas publicado para esse caso. Anchors e aliases YAML reduzem repetição dentro do documento, mas não constituem distribuição central de políticas entre repositórios.
Cliente dentro do contentor do job: postgres:5432. Cliente no host: confirmar a porta publicada.
Armadilhas comuns
Env como global; output sem mapeamento; localhost universal; alias YAML como política distribuída.
Tópicos relacionados: Eventos, filtros e dependências · Reutilização, artifacts e diagnóstico · Actions com contratos e versões
Localiza o produtor, a fronteira e o consumidor de cada dado.
Referência: Workflow commands · GH-200 skills measured January2026;study guide updated2026-02-05