APRENDER. PRATICAR. EVOLUIR.O YAML é uma parte das entradas
Uma revisão de release precisa de identificar a versão do executor, os ficheiros selecionados, a ordem dos overrides e os valores externos usados na interpolação. O mesmo YAML pode produzir referências de imagem diferentes. No laboratório original, inputs.env define DR_TAG=file-tag, mas a variável do processo com shell-tag prevalece quando fornecida. A imagem resolvida muda sem editar o ficheiro Compose. Para investigar uma diferença entre portátil e pipeline, começa por estas entradas e pelo modelo canónico, preservando a identidade do artefacto que foi realmente revisto antes da aplicação.
Vazio e ausente têm efeitos diferentes
O ensaio define DR_EMPTY como string vazia. A expressão com :- produz fallback, enquanto a forma com - conserva o vazio. A distinção interessa quando um valor vazio significa desativar uma opção ou quando a ausência deve selecionar um default. Evita corrigir uma falha removendo a restrição sem rever o contrato da aplicação. Para entradas obrigatórias, o laboratório usa :? e observa rejeição antes de gerar o modelo. O pipeline deve tratar esse resultado como uma pré-condição em falta, sem recorrer silenciosamente a uma configuração antiga.
Interpolação e ambiente do serviço
Uma variável disponível para construir o modelo não é automaticamente encaminhada para o processo do contentor. DR_UNUSED existe no ficheiro sintético de interpolação e não aparece no ambiente do serviço porque não foi declarada para esse fim. Noutro ensaio, service.env fornece DR_MODE e DR_EMPTY, mas environment substitui ambos, incluindo um valor explicitamente vazio. Revê separadamente as entradas de interpolação e as entradas destinadas à aplicação. O laboratório observa a estrutura resultante; não iniciou um contentor para inspecionar o seu ambiente em runtime nem leu variáveis privadas do utilizador.
A ordem de avaliação pode bloquear um override
No ensaio de entrada obrigatória, o ficheiro base usa DR_REQUIRED na imagem e o override fornece uma referência literal. Mesmo assim, a ausência da variável provoca erro. A interpolação por ficheiro acontece antes da junção, pelo que a referência posterior não evita a expressão obrigatória da base. Se uma equipa quer retirar essa dependência, deve rever a estrutura dos ficheiros ou fornecer uma entrada autorizada, em vez de presumir que o último campo elimina toda a avaliação anterior. Conserva o erro concreto no relatório para distinguir esta situação de uma falha de registry.
Escapes e output exigem leitura cuidadosa
O caso command com printf e $$DR_TAG conserva o escape no JSON canónico. Nenhum processo é iniciado, pelo que não existe evidência de expansão numa shell ou de valor recebido pela aplicação. A forma de comando precisa de corresponder à intenção de execução. Também deves rever o destino do output de config: pode conter valores resolvidos que não devem ser publicados num ticket. Nesta experiência todos os valores são fictícios e o runner usa uma configuração Docker vazia. Num ambiente real, conserva evidência útil com acesso e divulgação adequados.
Oficina de reprodução sem confundir validações
Prepara um registo com versão Compose 2.40.3-desktop.1, ficheiros por ordem, entradas fictícias e resultados esperados. O runner executou config com um socket Unix inexistente e obteve modelos válidos, demonstrando que este teste não exige um serviço em execução. Não afirma que uma imagem existe, que um volume está disponível ou que o consumidor funciona. Para uma mudança fictícia de fundos, usa o modelo como primeiro gate e acrescenta posteriormente verificações autorizadas de runtime e aceitação. Em inglês: “The configuration model passed; runtime and consumer validation remain outstanding.”
inputs.env seleciona file-tag; uma variável do processo seleciona shell-tag. Com DR_EMPTY vazio, :- escolhe fallback e - mantém vazio. O ensaio observa JSON do CLI, sem contentores.
Armadilhas comuns
Tratar --env-file como injeção automática no contentor; confundir vazio com ausente; presumir que um override evita toda a interpolação anterior; usar config como prova de disponibilidade.
Tópicos relacionados: Build e distribuição · Dados e mounts · Diagnóstico e recuperação
Regista as entradas que produziram o modelo e o alcance do teste. Uma configuração resolvida é uma etapa verificável, mas ainda precisa de aplicação e aceitação no contexto correto.
Referência: Set, use, and manage variables in a Compose file with interpolation · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped