Posted on Leave a comment

Build triggers on Azure devops pipelines

Continuous integration (CI) triggers cause a pipeline to run whenever you push an update to the specified branches or you push specified tags. Build in triggers can become a powerful tool for your build strategy and the most common scenarios will be explained using the examples below.

Continuous integration triggers:

Branches:
Those will trigger your pipeline when a new commit is performed on your branch. In the scenario below the pipeline will run if code is merged on your main branch or a branch starting from releases like release1, release-1 releases etc. Also the pipeline will not run if a push is commited on uat branch. This is excluded through the exclude keyword.

trigger:
branches:
include:
- main
- release/*
exclude:
- uat

Tags:
Those will trigger your pipeline only when a tag is pushed on your repository. Tags are bound with a commit on a git source control system. In the scenario below the pipeline will get triggered if a tag is pushed following the v.* regex like v.1 , v.something, v.2 etc. Also it will not run if the tag that is pushed starts with uat keyword for example uat-1 will not trigger the pipeline.

trigger:
tags:
include:
- v.*
exclude:
- uat*

Pull Requests:
pr keyword will trigger your pipeline if a pull request is created from a branch and the destination is the noted one. For example if you create a new pull request from mybranch to current branch then the pipeline will get triggered. The pipeline will not trigger if a pull request is created from any branch to uat branch as it is excluded.

trigger:
pr:
branches:
include:
- current
exclude:
- uat

One powerful tool that you can combine with your build strategy is paths. When you specify paths, you must explicitly specify branches to trigger on. You can’t trigger a pipeline with only a path filter; you must also have a branch filter, and the changed files that match the path filter must be from a branch that matches the branch filter.

Paths:
Using a path you specify a directory/folder which will trigger the build. For example you may want only to trigger a build when particular files are changed on your repository. In the below example the pipeline will get triggered if files inside the docs folder change for the branches master and releases*

trigger:
branches:
include:
- master
- releases/*
paths:
include:
- docs
exclude:
- docs/README.md

Microsoft documentation for build strategies:

https://docs.microsoft.com/en-us/azure/devops/pipelines/repos/azure-repos-git?view=azure-devops&tabs=yaml#ci-triggers

Posted on Leave a comment

Trigger azure Devops pipeline from another repository

For security reasons you may want to store the pipelines to another repository than the one that the code is hosted. Lets say for example that you have your application code located on test-project/repository location but your pipelines are stored on the consoleapp1 repository. Also you want to have continuous integration and deployment for the repository on which the code is hosted, so when code is pushed to repository then the pipeline should trigger which is hosted on ConsoleApp1.

You can do that using the repositories resource of azure devops. You will need to define the repository and also configure trigger for this repository based on your strategy.

The final result would be the pipeline to run when code is commited on the code repository instead of the one that pipelines are hosted.

Posted on Leave a comment

Push multiple docker container images using a loop – Azure DevOps

On a pipeline that I was creating I wanted to push multiple docker images on an Azure container registry based on a list. In order to do that I used the docker@2 task on a loop providing the images that I had to push as a parameter. Code is attached below.

trigger:
– none
pr: none
parameters:
– name: containerlist
type: object
default: ["core/image1","core/image2","core/image3","core/image4"]
– name: DockerPushID
type: string
pool:
name: demo-app
stages:
– stage: containers
displayName: Push containers to container registry $(registry)
jobs:
– job: pushcontainers
displayName: Push containers on testexample.azurecr.io
steps:
– checkout: none
– ${{ each container in parameters.containerlist }}:
– task: Docker@2
displayName: pushing image ${{container}}
inputs:
containerRegistry: 'registryconnection'
repository: '${{container}}'
command: 'push'
tags: |
current-${{parameters.DockerPushID}}
current-latest

This task will run steps based on the images you provide on the parameters list. An important note is that you need to have the image named accordingly in order to get a successful result. For example if you need to push on geralexgr.azurecr.io you will need to have your images named as below.

geralexgr.azurecr.io/image1:current-latest
geralexgr.azurecr.io/image2:current-latest

Else you may notice some failures indicating the below.

The push refers to repository [***/kati/image1] 
An image does not exist locally with the tag: ***/kati/image1

A successful run of the pipeline.

Additional information regarding loops and expressions on Azure DevOps pipelines:

https://docs.microsoft.com/en-us/azure/devops/pipelines/process/expressions?view=azure-devops#functions

Video tutorial on YouTube: