Task Life Cycle

A task life cycle represents the sequence of states and transitions that a task goes through during its execution in a release. Understanding these states and transitions is crucial for effectively managing and monitoring tasks within your release pipeline.

This topic illustrates the lifecycle of a task, detailing how tasks transition through different states in an active release.

note

Tasks initially start in a planned state where they remain inactive and fully editable.

Active Task States

When the release flow reaches a task and activates it, the task can transition through several states based on specific conditions:

• If a scheduled start date is configured and hasn't been reached, the task enters the pending state
• If any required variables in the task lack values, the task moves to the ask for input state

Once all variables are populated or a user manually starts the task, the system evaluates it for a precondition. The subsequent state depends on the precondition script's evaluation:

• True: The task transitions to in progress state, triggering notifications to the task owner. At this point, you can initiate the next transition by selecting Complete, Skip, or Fail
• False: The task automatically moves to skipped state

Task Completion States

The completion phase represents the final stages of a task's lifecycle. Here's how tasks reach their completion states:

When you complete a task manually or when an automated task executes successfully, it enters the completed state. This final state indicates successful completion, allowing the release flow to proceed to the next task.

You have the option to skip tasks that are either in progress or failed. When skipped, the task enters the skipped state, which functions similarly to completed but indicates that no actual work was performed.

Additionally, tasks can be marked as completed or skipped proactively, before the execution flow reaches them. These advance completions appear in the release flow editor, and you can reopen them (returning them to planned state) until the release flow actually reaches the task. Once the flow reaches a pre-completed or pre-skipped task, the state becomes permanent and can no longer be reopened.

Failed Tasks

If a user fails a task or an automated task encounters an error, the task goes into the failed state, triggering a notification to the release owner. The task can then be either restarted (in progress state) or skipped if no more work will be done (skipped state).

If the task has the failure handler enabled, the task changes state to failure handler in progress and, depending on the configuration, the end state can be in progress, skipped, or failed.

If a user aborts a task manually, by default the task goes to the failed state. If the user is aborting a script task that has an abort script, the abort script will be executed before the task goes to the failed state.

Failing Tasks

The failing state is an intermediate state that occurs when partial failures are detected but task execution hasn't fully completed. This state is particularly relevant for parallel group tasks and gate tasks.

note

The Failing state behavior for gate tasks is controlled by an experimental feature setting, which is enabled by default. For more information, see the Experimental Settings, section Gate Task Failing Status.

Parallel Group Task Transitions

When dealing with parallel group tasks that contain subtasks, the following transitions can occur:

• A task enters the failing state when at least one subtask fails while others are still running
• The task can return to in progress if all failed subtasks are either restarted or skipped, with other tasks still executing
• The task remains in failing if some subtasks are still failed while others continue execution
• The task moves to failed state when all remaining subtasks complete or fail

Gate Task Transitions

For gate tasks with dependencies, the state transitions follow this pattern:

• In Progress ➔ Failing: Occurs when one or more dependencies enter Failed/Failing state
• Failing ➔ In Progress: Happens when all previously failed dependencies are retried or skipped
• Failing ➔ Failed: Occurs only when the task is manually failed or when one or more dependencies are aborted
• Failed ➔ In Progress: When a failed Gate task is retried and there are no dependencies in a Failed/Failing/Aborted state

A gate task with failing or failed dependencies will remain in the failing state until either:

• Failed dependencies are retried successfully (moves to in progress) or skipped
• The task is manually failed (moves to failed)
• One or more dependencies are aborted (moves to failed)

note

A gate task transitions to completed only when all its dependencies (releases, phases, or tasks) are either completed or skipped. If any dependency remains in progress, the gate task maintains its in progress status.

Status messages during these transitions clearly indicate the reason for the task state:

• When entering failing state: "Task started failing because one or more dependencies have failed"
• When returning to in progress: "Task is now In progress because all previously failed dependencies have been retried"

Completion of Gate Tasks

Gate tasks with no conditions and only dependencies will complete immediately when their dependencies are complete. If all dependencies are complete but at least one of the dependencies is an aborted release, the gate task goes into a failed state. If any conditions are set, the owner of the task must complete the gate task manually.