Promotion Templates Reference
Promotion Templates define how Kargo transitions Freight
into a Stage
by
executing a series of discrete, composable steps. Each step in a promotion
template performs a specific action, from simple operations like cloning a
Git repository to complex workflows like managing the lifecycle of a pull
request.
When Freight
is promoted to a Stage
, Kargo uses the promotion template
associated with that Stage
to create a Promotion
object which orchestrates
the promotion process.
Defining a Promotion Template
A promotion template is defined within a Stage
's configuration using the
spec.promotionTemplate
field. The template contains two main components:
- Global variables that provide configurable values for the promotion process
- Steps that define the sequence of actions to perform
apiVersion: kargo.akuity.io/v1alpha1
kind: Stage
metadata:
name: test
namespace: kargo-demo
spec:
# ...
promotionTemplate:
spec:
# Template-wide variables
vars:
- name: gitRepo
value: https://github.com/example/repo.git
# Sequence of promotion steps
steps:
- uses: git-clone
config:
repoURL: ${{ vars.gitRepo }}
checkout:
- branch: main
path: ./src
- task:
name: update-manifests
kind: PromotionTask
Variables
Variables provide a way to define reusable values that can be referenced throughout the promotion template. They can be used to parameterize steps, making the template more flexible and easier to maintain.
You can define variables at two levels: globally for the entire template, or scoped to a specific step. Global variables are perfect for values you want to use throughout the promotion process, like repository URLs or branch names.
To define global variables, use the vars
field in the spec
of the promotion
template. The value of the vars
key is a list of variables, each of which is
an object with name
and value
keys.
vars:
- name: gitRepo
value: https://github.com/example/repo.git
- name: targetBranch
value: stage/${{ ctx.stage }}
Once defined, you can reference these variables throughout the template using
${{ vars.<variable-name> }}
.
steps:
- uses: git-clone
config:
repoURL: ${{ vars.gitRepo }}
checkout:
- branch: ${{ vars.targetBranch }}
path: ./target
Global variables can use expressions within ${{ }}
to
compute values dynamically, including references to context variables like
ctx.stage
.
They do not support referencing outputs from steps. To reference outputs, use step-specific variables.
Variables defined at the template level are available to all steps within the template. You can override these values within individual steps by defining step-specific variables.
Steps
The steps
section in the spec
of a promotion template defines the sequence
of actions to perform during the promotion process. Steps come in two forms:
- Steps that reference a built-in promotion step
- Steps that reference a
PromotionTask
orClusterPromotionTask
Built-in Steps
A step can be used to reference a built-in promotion step using the uses
key
whose value is the name of the step.
steps:
- uses: step-name
For a list of built-in promotion steps and configuration options, see the Promotion Steps Reference.
Promotion Task Steps
A step can be used to reference a
PromotionTask
or ClusterPromotionTask
using the task
key, whose value is an object with a name
key that specifies
the name of the task and optionally a kind
key that specifies the kind of task
to reference. The kind
key is optional and defaults to PromotionTask
.
steps:
- task:
name: task-name
kind: ClusterPromotionTask
Steps referencing PromotionTask
or ClusterPromotionTask
do not support
configuration or retry options like built-in step, as the steps within the
task define their own configuration. For more information, see the
Promotion Tasks Reference.
Step Variables
A step can define variables that can be referenced in its configuration by
providing a vars
key in the step definition. The value of the vars
key is a
list of variables, each of which is an object with name
and value
keys.
steps:
- uses: step-name
vars:
- name: var1
value: value1
- name: var2
value: value2
config:
option1: ${{ vars.var1 }}
option2: ${{ vars.var2 }}
Variables defined in a step are scoped to that step and are not accessible to other steps like global variables are. The values of variables may contain expressions. In addition, the values of step variables may contain references to the outputs of other steps.
steps:
- uses: step-name
as: step1
- uses: another-step
vars:
- name: var1
value: ${{ outputs.step1.someOutput }}
Step variables with the same name as global variables will override the global value for that step.
Step Configuration
Each step in a promotion template can be configured with a set of options that
control its behavior. The config
key in a step definition is an object that
contains the configuration options for the step.
steps:
- uses: step-name
config:
option1: value1
option2: value2
The configuration options available for a step are specific to the step itself and are documented in the Promotion Steps Reference.
Step Outputs
A promotion step may produce output that can be referenced by subsequent steps, allowing the output of one step to be used as input to another. The output of a step is defined by the step itself and is typically documented in the step's reference documentation.
steps:
- uses: step-name
as: alias
- uses: another-step
config:
input: ${{ outputs.alias.someOutput }}
Step Retries
When a step fails for any reason, it can be retried instead of immediately
failing the entire Promotion
. An error threshold specifies the number of
consecutive failures required for retry attempts to be abandoned and the
Promotion
to fail.
Independent of the error threshold, steps are also subject to a timeout. Any
step that doesn't achieve its goal within that interval will cause the
Promotion
to fail. For steps that exhibit any kind of polling behavior, the
timeout can cause a Promotion
to fail with no other failure having occurred.
System-wide, the default error threshold is 1 and the default timeout is indefinite. Thus, default behavior is effectively no retries when a step fails for any reason and steps with any kind of polling behavior will poll indefinitely as long a no other failure occurs.
The implementations of individual steps can override these defaults. Users also
may override these defaults through configuration. In the following example, the
git-wait-for-pr
step is configured not to fail the Promotion
until three
consecutive failed attempts to execute it. It is also configured to wait a
maximum of 48 hours for the step to complete successfully (i.e. for the PR to be
merged).
steps:
# ...
- uses: wait-for-pr
retry:
errorThreshold: 3
timeout: 48h
config:
prNumber: ${{ outputs['open-pr'].prNumber }}
This feature was introduced in Kargo v1.1.0, and is still undergoing refinements and improvements to better distinguish between transient and non-transient errors, and to provide more control over retry behavior like backoff strategies or time limits.