APRENDER. PRATICAR. EVOLUIR.Etiqueta e seleção são decisões diferentes
Adicionar tags a uma tarefa não manda executar apenas essa tarefa. A seleção resulta dos argumentos da execução e da configuração efetiva. Num incidente fictício, uma equipa corre --tags deploy para reduzir a janela, mas a verificação pós-mudança tem apenas a tag verify. O processo pode terminar sem erro porque executou exatamente o subconjunto pedido, deixando a aceitação por fazer. Define o contrato de cada modo de execução: entradas necessárias, pré-condições, alterações e verificações finais. Guarda os argumentos juntamente com a revisão do playbook. O mesmo commit com --tags diferente pode representar outra mudança operacional. Não uses nomes de tags como substituto de uma descrição dos efeitos nem suponhas que selecionar deploy inclui automaticamente todas as suas dependências.
Herança estática e seleção dinâmica
Num import_tasks com tags:deploy, as tarefas importadas herdam a tag e ficam elegíveis para --tags deploy. Num include_tasks com a mesma tag, a etiqueta aplica-se à inclusão, sem ser automaticamente copiada para os filhos. O laboratório mostra a inclusão executada e o ficheiro de deployment ausente porque a tarefa filha não tinha a tag pedida. Para aplicar a tag aos filhos, usa apply: tags:deploy no include; para que o include seja alcançado nessa execução filtrada, seleciona também a própria inclusão. O ensaio inclui uma variante só com apply, sem tag exterior: o include é saltado e o filho nunca é carregado. Trata as duas decisões separadamente ao ler a configuração.
Always e never não são controlo de autorização
Uma tarefa com always pode ser executada apesar de uma seleção normal por tags, mas --skip-tags always pode excluí-la. No ensaio, um assert de aprovação sintética bloqueia a escrita quando falta aprovação; a execução que exclui always passa à escrita sem avaliar esse assert. Isto demonstra o efeito de seleção, não um método aceitável para ultrapassar uma aprovação real. Controla quem pode escolher argumentos e efetuar a operação através do mecanismo de acesso e do processo de mudança adequados. Por sua vez, never evita a execução por defeito, mas uma seleção explícita de never ou de outra tag da mesma tarefa pode fazê-la correr. No exemplo, tags:[never,maintenance] permite a execução com --tags maintenance. Never não significa impossibilidade de execução.
Precedência e trabalho omitido
Quando uma tarefa é simultaneamente selecionada e excluída por tags, a exclusão tem de ser considerada. O ensaio pede --tags never e --skip-tags maintenance para a tarefa com ambas; o marcador não é escrito. Inspeciona os dois argumentos e os defaults relevantes, não só a opção positiva. Há também validações implícitas ou tarefas de recolha de facts que podem usar always; alterar a seleção pode retirar dados ou verificações de que o resto do trabalho depende. Uma falha por variável ausente após execução parcial pode ser consequência de uma tarefa preparatória omitida, sem existir defeito no template. Ao diagnosticar, compara a execução integral e a seleção problemática, observa o que correu efetivamente e mantém os mesmos dados de entrada.
Construir uma matriz de aceitação
Uma matriz útil regista cada combinação suportada de tags, entrada e estado inicial, mais os efeitos esperados e as verificações obrigatórias. Inclui pelo menos uma execução integral, uma seleção operacional legítima, uma combinação que deve falhar e uma que deve deixar o estado intacto. No laboratório, 19 invocações de Ansible por passagem suportam 40 verificações, incluindo códigos de saída esperados, ficheiros presentes ou ausentes e erros deliberados. Foram feitas duas passagens com os mesmos resultados observáveis. Um código zero isolado não prova deployment: uma seleção pode saltar todo o trabalho útil. No handover, documenta apenas modos ensaiados, os limites da simulação local e os controlos ainda necessários no alvo. Seleção por tags deve reduzir trabalho autorizado sem retirar a evidência necessária para o aceitar.
# Select the include and apply the selection to its children:
- name: Include deployment tasks
ansible.builtin.include_tasks:
file: deploy.yml
apply:
tags: deploy
tags: deploy
# From the project root, with an isolated core 2.16.14 environment:
# python3 content/labs/rhce-reuse-selection/run.py \
# --ansible-bin /path/to/venv/bin/ansible-playbook \
# --output /tmp/rhce-reuse-evidence.json
# Synthetic local files; not a RHEL service or an authorization system.
A pipeline termina com sucesso em --tags deploy, mas a tarefa incluída não herdou a tag. O artefacto esperado não existe e a entrega não pode ser aceite.
Armadilhas comuns
Tags como dependências automáticas; apply como seleção da inclusão; always como impossível de saltar; never como bloqueio absoluto; exit zero como prova de efeito.
Tópicos relacionados: Imports e includes · Controlo de mudanças e handover
Valida o subconjunto que realmente executaste e os requisitos que ele deixou por cumprir.
Referência: Tags and inheritance · EX294 current objectives inspected 2026-09-30; RHCE in Ansible framework effective 2026-05-11; booking product version not publicly pinned