One of the key features of Pipelines resource is versioning. Resource versions are useful for controlling the flow of pipelines and tracking the changes that a resource undergoes over time. You can trigger runs using specific versions or skip steps in the same run when input resources are not updated.
Every resource starts with an initial version, which is updated every time the resource changes. For example, the version of an Image resource used in a pipeline is updated whenever a new tag is pushed to a Docker image. Pipelines tracks these changes by updating the resource version, which is based on the metadata received for that particular resource.
A new resource version is created when:
The resource definition is updated in the pipelines YAML file.
An output resource is updated during a run.
There is an external event, such as pushing a commit to a git repository.
Note
No new version is created for an unchanged resource. However, if you need the resource to always change (for example, to trigger another pipeline), you can add $run_id environment variable as the value of an additional property.
Each version of a resource is immutable and returns the same result every time a specific version is used for a run. By default, steps always run using the latest version of an input resource. However, because a resource is versioned and holds the entire history of all the available versions, a run can be customized to use a specific version of a resource. For more information, see Triggering a Run with Custom Parameters.
Default Behavior of Resource Versions
Resource versions have the following default behavior:
Latest version: When a run is triggered, the latest version of the input resource is used in that run.
Dependent step in the same pipeline: During a run, even when an input resource is not updated (no new version), the dependent step is triggered. While this is the default behavior, it can be changed by setting the
newVersionOnly
tag astrue
.Note
This is applicable only for generated resources, which are resources that connect two steps of a pipeline.
Dependent step in another pipeline: During a run, the dependent pipeline is triggered only when there is a new version of the resource that connects the pipelines.
Example - Resource Versions
This is a simple, single-step pipeline, with GitRepo as the input resource for the step.
In this example:
First version: When the pipeline syncs and loads for the first time, the latest commit on the Git repository is seeded as the very first version for the Gitrepo resource.
When the first run is triggered, this resource version is used for the run.
Second version: When a new commit is pushed to the Git repository, the Gitrepo resource is updated with the new version, which becomes the latest version of the resource.
The Git commit automatically triggers the run and the second version of the resource, which is now the latest, is used for the run.