top of page
Search
  • Writer's pictureNathan

Azure DevOps YAML Pipelines - Part 4

Updated: Jan 15

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.

 

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:

  1. You need to consume and use that Resource in your Pipeline steps

  2. 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:

  1. From a Pipeline Job configured to run inside a Container (aka Container Jobs)

  2. From a Pipeline Step configured to run inside a Container (aka Step Target)

  3. 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:

  1. Trigger on updates to a build from a hosted Jenkins server

  2. Trigger on updates to a container image (possibly ACR only)

  3. Trigger on updates to Nuget or NPM packages on GitHub Packages

  4. Trigger on successful pipeline runs from other Azure Pipelines

  5. Trigger on updates to an Azure Repos Git repository

  6. Trigger on any custom Webhook


Next up, we'll be discussing Pools and Agents.

Part 5 - Pools and Agents


67 views
bottom of page