LEARN. PRACTICE. GROW.Resolve now or during execution
Imports and includes both reuse tasks, but resolution timing changes the design. Import_tasks is static: the file is processed before execution, and values required to identify that file must be available at that stage. Include_tasks is dynamic and can use values obtained during the play. This does not remove validation: if an external response chooses a file, restrict selection to the authorized set. A loop can iterate a dynamic include; do not simply transfer that loop to a static import. Choose the mechanism according to runtime needs and the ability to review effective scope.
Inherited conditions can change halfway through
A condition on a static import is applied to each imported task. If the first task changes the value used by that condition, the second may be skipped. In the release_id is not defined example, defining release_id in the first task makes the condition false for later tasks. A conditional dynamic include evaluates the condition at the include; once the file is included, children do not automatically inherit that condition. Before replacing one mechanism with the other, explain the intended behavior. The difference can affect directory preparation, version selection, or checks the operator expected to run together.
Tags on the include and on tasks
A tag applied to a dynamic include_tasks selects the include without automatically being inherited by every child. Under --tags release, the include can appear while inner tasks lacking matching tags do not run. Apply.tags can apply tags to children, but the include itself must also be selected. With a static import, tag inheritance follows a different rule and propagates to imported tasks. Do not choose the static form merely to hide a selection problem. Document the supported-mode matrix, expected steps in each mode, and the observation confirming that selection matched the intention.
Listing and resumption have limits
List-tasks and list-tags do not reveal all inner dynamic-include content as they reveal static tasks. A short listing does not establish an empty file or an execution without effects. Inspect the contents and values selecting the path. Start-at-task also cannot begin inside a dynamic include. To resume after partial failure, define supported entry points, preconditions, and state reconciliation. That may require an explicit recovery mode. A readable task name does not replace checking that directories, version, permissions, and data correspond to the state from which resumption begins.
Workshop: establish two selection paths
The lab runs a localhost play with --tags release. The first include has only the include-level tag and points to an untagged task that would create a marker. The second has the include tag and apply.tags for its child, which creates another marker. The runner checks that the first file does not exist and the second does. All files are temporary. This experiment establishes the selection difference in ansible-core 2.21.4 without establishing any real pipeline’s safety. As an exercise, design a third path that includes readiness validation and explain the evidence needed before accepting the release.
Summary: selection does not implement dependencies
Tags are execution filters, not an automatic dependency or authorization model. Always can be explicitly skipped and never can run when a matching tag is requested; neither is a security barrier by itself. If a pipeline permits deploy without readiness, acceptance remains unestablished even when every selected step finishes without error. Define authorized modes and validate their preconditions, observations, and decisions. At operational handover, record the command and effective selection. Connect this lesson with asynchronous tasks and per-item results: a global completion statement is useful only when scope and criteria are known.
# Both levels need selection under --tags release.
- name: Release steps
ansible.builtin.include_tasks:
file: release.yml
apply:
tags: release
tags: release
# Validate the selected path and its acceptance checks separately.A tag on a dynamic include can select only the include. apply.tags and selection of the include itself cover different levels.
Common pitfalls
Assuming automatic inheritance in includes; selecting static files with unavailable values; relying only on list-tasks; treating always as authorization.
Related topics: Inventory and execution context · Batch orchestration · Failures and recovery
Selecting a task does not prove that dependencies and checks also ran. Make the path, limits, and resumption conditions explicit.
Reference: Tags · Ansible community 14 / ansible-core 2.21 documentation consulted 2026-09-30; executor, collection and plugin compatibility requires confirmation