Gate Tasks
This guide explains how to use Gate tasks in Release, including configuration of checkbox conditions, dependencies, transitions, and advanced options for controlling release flow.
A Gate task contains conditions that must be fulfilled before the release can continue.
There are two types of conditions: simple checkboxes and dependencies on other releases.
In the release flow editor, Gate tasks are marked with a red border.
Checkbox Conditions
When you open a Gate task, you will see the checkbox conditions on the task. If you have the Edit task release permission, you can add a checkbox by clicking Add condition. To remove a condition, click the cross icon.
Checkboxes must be completed by users who are involved in the release. When a Gate task is active, it can only be completed after all of its checkboxes have been ticked indicating that the conditions are met. The Gate task will not automatically complete when the conditions are met. The task assignee must mark it as complete.
Checkboxes must be completed by users who are involved in the release. When a Gate task is active, it can only be completed after all of its checkboxes have been ticked indicating that the conditions are met. As of 9.7.0, the Gate task will be completed automatically when the conditions are met. This setting is enabled by default, running every 10 minutes and completing the task if the gate task has been executing longer than the graceDuration
(5 minutes default).
You can tweak the graceDuration
as per your requirement to control when gate tasks autocomplete.
To configure or disable this feature, add the following to your xl-release.conf
file:
xl {
features {
gate-actor {
enabled = true
graceDuration = 5 minutes
unstuckInterval = 10 minutes
}
}
}
Dependencies
The Gate task also shows dependencies on other releases. A Gate task can wait on other releases, on the level of release, phase, or task.
To create a new dependency, click Add dependency. Click an existing dependency to edit it.
Select the conditions for the dependency:
- The release the Gate will wait on (only current releases are displayed)
- The release phase the Gate will wait on (optional)
- The release task the Gate will wait on (optional)
If the Gate contains dependencies and no conditions, it completes automatically when all dependent releases, phases, or tasks are complete.
When a dependent task or release fails, the Gate task usually enters a Failing state. It waits until the dependency is retried and completed or skipped, then automatically resumes.
However, if the Fail if any dependency fails flag is enabled in the release template, the Gate task immediately transitions to Failed when any dependency fails. In this case, it must be manually retried or skipped, even if the dependency is fixed.
A Gate task still fails automatically if a release it depends on is aborted.
Gate Task Transitions
For gate tasks with dependencies, the state transitions follow this pattern:
The Failing state behavior for gate tasks is controlled by an experimental feature setting. This feature is enabled by default. For details, see the Experimental Settings, section Gate Task Failing Status.
Fail if Any Dependency Fails
A new flag, Fail if any dependency fails, is available for gate task dependencies. This flag is disabled by default.
When the flag is enabled:
- The gate task will fail immediately and turn red if any one of its dependencies fails.
- It won’t resume automatically, even if the dependency is fixed.
- You’ll need to manually retry or skip the gate task to continue the release.
When the flag is disabled (default behavior):
- In Progress ➔ Failing: Occurs when one or more dependencies enter Failed/Failing state
- Failing ➔ In Progress: Happens when all previously failed dependencies are retried successfully 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)
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 changes are immediately reflected across all affected gates for these actions:
- Adding new dependencies
- Removing existing dependencies
- Updating dependency status
Status messages during transitions clearly indicate the task state change:
- 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"
Nested Gate Tasks
For gate tasks that depend on other gate tasks (nested gates):
- Status changes cascade through the hierarchy - When a nested gate's state changes (e.g., to failing), the parent gate updates automatically
- Dependency changes affect related gates - Adding or removing dependencies in a nested gate updates the parent gate's status
- State transitions maintain consistency - All gates in the hierarchy stay synchronized with proper status updates
Using Variables in Dependencies
To use variables instead of direct release dependencies, click and select a variable of type text. Release searches for a release, phase, or task with the ID stored in the variable. If the ID is valid, the variable dependency is replaced with a normal dependency and the release proceeds as usual. If the ID is not valid, does not exist, or is empty, the Gate task fails.
You can use this feature in combination with the Create Release task to start a release and require the initial release to wait at the Gate until the new release is complete.