Pipeline Resources
There are a lot of topics to cover for YAML-based Pipelines in Azure DevOps. So, I will be breaking this up into a multi-part series. This section will be updated over time with links to the whole series of articles once they are written.
Part 1 - The Basics
Part 2 - Structure of a YAML Pipeline
Part 3 - Pipeline Triggers
Part 4 - Pipeline Resources (you're reading it now!)
Part 5 - Pools and Agents
Part 6 - Parameters and Variables
Part 7 - Stages, Jobs, and Steps
There are 6 different types of Resources that you can define in your Pipeline. They are builds, containers, packages, pipelines, repositories, and webhooks.
There are 2 reasons that you would define Resources in your Pipeline:
You need to consume and use that Resource in your Pipeline steps
You need to trigger your Pipeline based on updates to the Resource
We'll go over each type of Resource below, how to consume it in your Pipeline, and how to use it to trigger your Pipeline.
Builds
These are artifacts created by an external CI system.
Builds are not automatically downloaded by Jobs. So, in order to consume a Build in your Pipeline, you must add a downloadBuild step (which is a shortcut for the DownloadBuildArtifacts task).
Triggers for Builds are ONLY supported for hosted Jenkins where Azure DevOps has line of sight with the Jenkins server. Triggers for Builds are very basic and only support none or true. The default is none so your Pipeline will not automatically trigger if the Build artifact is updated.
Containers
These are container images stored in Docker Registry or Azure Container Registry
Consuming a Container in your Pipeline can be done in a few different ways:
From a Pipeline Job configured to run inside a Container (aka Container Jobs)
From a Pipeline Step configured to run inside a Container (aka Step Target)
From a Pipeline Job that uses Service Containers
All 3 of the above options can use a Container defined from the Resources section. All 3 of these options will be covered in a later post.
The documentation is not crystal clear, but I believe Triggers will only work with containers from Azure Container Registry. Triggers for Containers can use one of a few different styles:
The default is none so your Pipeline will not automatically trigger if the Container image is updated.
Packages
These are Nuget or Npm packages stored on GitHub Packages
The GitHub Service Connection mentioned above must use Personal Access Token (PAT) authentication. This is the only type that GitHub Packages supports.
Packages are not automatically downloaded by Jobs. So, in order to consume a Package in your Pipeline, you must add a getPackage step (which is a shortcut for the DownloadPackage task).
Triggers for Packages are very basic and only support none or true. The default is none so your Pipeline will not automatically trigger if the Package is updated.
Pipelines
These are other Azure DevOps YAML Pipelines
Artifacts produced by Pipeline resources are not automatically downloaded by 'regular' Jobs, but they are automatically downloaded by 'deploy' jobs. To consume Artifacts from Pipeline resources in 'regular' Jobs use a Download Step or a DownloadPipelineArtifact Task.
Artifact Versions
If your parent Pipeline is run manually or by scheduled trigger, then it needs to know which 'version' of the Pipeline Resource Artifact to reference. This can be defined by the top-level version:, branch:, and tags: parameters as shown above.
Otherwise, if the Pipeline Resource causes the parent Pipeline to trigger, then the 'version' of the Pipeline Resource Artifact that's used is the one which caused the trigger.
Branch used by Parent Pipeline
When the parent Pipeline is triggered, then which branch will it run under:
If both Pipelines are located in the same repository, and the Pipeline Resource was updated on Branch-A, then the parent Pipeline will be run using that same Branch-A
If both Pipelines are located in different repositories, then it doesn't matter which branch the Pipeline Resource was updated on, the parent Pipeline will always be run from its own default Branch
Triggers for Pipeline Resources:
tags: are AND'ed, meaning every tag listed must be present
stages: are AND'ed, meaning every stage listed must be completed successfully
Repositories
These are source code repos
Repositories are not automatically downloaded by Jobs. So, in order to consume a Repository in your Pipeline, you must add a checkout step.
For Azure Repos Git you must specify type: git
If the Azure Repo exists in the same Azure DevOps Project, then you can use name: someRepo
If the Azure Repo exists in a different Azure DevOps Project, then you must use name: someProject/someRepo
For other types of repos you must use name: orgName/someRepo
Triggers for Repositories are ONLY supported for Azure Repos Git. They can use one of a few styles:
You need to specify either branches: or tags: or you could even specify both. If you specify both, then both of them will be evaluted. If at least one of them matches, then the pipeline will be triggered.
The paths: parameter cannot be used by itself, it can only be used in combination with the branches: parameter. Paths in Git are case-sensitive.
Webhooks
These are external services that can be used to trigger your pipeline
filters: are AND'ed, meaning every filter listed must be matched
To consume the webhook's JSON payload in your Pipeline, you can use a parameter with the format ${{ parameters.webhookSymbolicName.jsonPath }}
When creating the Webhook in the external service, make sure to point it at: https://dev.azure.com/yourOrgName/_apis/public/distributedtask/webhooks/yourWebhookSymbolicName?api-version=6.0-preview
To summarize, we discussed the 6 different types of resources that you can define in the Resources section of your Pipeline. Each one can be used to trigger your Pipeline, they can be consumed in your Pipeline, or both. To quickly highlight the Triggers:
Trigger on updates to a build from a hosted Jenkins server
Trigger on updates to a container image (possibly ACR only)
Trigger on updates to Nuget or NPM packages on GitHub Packages
Trigger on successful pipeline runs from other Azure Pipelines
Trigger on updates to an Azure Repos Git repository
Trigger on any custom Webhook
Next up, we'll be discussing Pools and Agents.
Kommentare