Azure DevOps : how to disable CI trigger on a YAML template pipeline?

Question

In template pipelines you can't place any trigger statement such as trigger: none as specified in Microsoft's docs to disable ci trigger, so I wonder how do you prevent these pipelines from being executed every time you update them or any other yaml file in the same branch?

Pelage

Answer 1

So in the end in a template pipeline you can't state something like trigger: none (to set only manual triggering) and you cannot specify stages or jobs, only steps are allowed (so you can't define any condition to prevent pipeline execution on the job or on the stage).

You have an option to disable the CI trigger by going in the triggers section for the template pipeline and select the following:

I don't like much this option because it means having pipeline configuration that is not captured in the yaml pipeline definition but I found no other way to disable the template pipeline from being triggered every time something (including the pipeline itself) is updated in its branch.

Pelage

everytime we create a pipeline we have to do this and it is really inconvenient – Agglutinative

Yes, but templates need not be registered as pipelines themselves - you just reference them as files. The error I made here was that of registering templates as pipelines and since they don't allow setting trigger: none they were constantly firing at every file update. – Pelage

Answer 2

The pipeline yaml definition now supports disabling all trigers with

trigger: none

Reference

Schmeltzer

That's all I had to do to get rid of it, as I hadn't added it to the new pipeline definition - something to remember – Prayerful

Apparently not. There are two otherspots I had to check to disable https://mcmap.net/q/327128/-azure-devops-how-to-disable-ci-trigger-on-a-yaml-template-pipeline. Very annoying – Inverson

Answer 3

First you need to go to your Pipelines dashboard, then select the pipeline that you want to disable CI for it

then Click on Edit

You will be redirected to the pipeline yaml file, from there you will click on the vertical ellipsis ⋮ => Triggers

and here you go, you can disable CI for your pipeline that easily

Save it, and you are done.

Tic

Answer 4

Other answers are fine.

Here is another approach I found. I have a yaml based build pipeline. I did not want to touch the yaml just for disabling the trigger. So I disabled the pipeline as follows.

1. Pick your pipeline and double click to edit it.

2. Go to the settings.

3. Now you should see an option to disable. Note here we are disabling the pipeline, not just disabling trigger to the pipeline.

Golda

Answer 5

If you want to update your template without affecting pipelines which uses this template make a change on separate branch and merge it to master (or whatever you use) once you are sure that you have what you want.

The same applies if you use template from different repo:

# Repo: Contoso/WindowsProduct
# File: azure-pipelines.yml
resources:
  repositories:
    - repository: templates
      type: github
      name: Contoso/BuildTemplates
      ref: refs/tags/v1.0 # optional ref to pin to

jobs:
- template: common.yml@templates  # Template reference
  parameters:
    vmImage: 'vs2017-win2016'

By default you use template from your main branch, but you can point to any branch you want. Thus you can also test that your changes on limited pipelines as you need to point directly to a branch where you modified your template.

Let's say you have that branching:

master
|_ feature/add-extra-step

And you make a change in template but on feature/add-extra-step by adding additional step.

Now hen you trigger pipeline which uses that template:

• trigger goes from master - your additional step in template won't be run
• trigger goes from feature/add-extra-step - your additional step will be run

I made a change in template on feature/extra-step branch:

And this is change is not avialable when I run pipeline (even the same pipeline) on master:

If you for instance don't want to trigger ci build making changes on template, pleace commit those changes with phrase [skip ci] in th git message. Check here for more details.

Cirri

I suppose this would work but it seems to me to somehow unnecessarily complicate things up. I was thinking, is anyway a good practice to have yaml files in the same branch or repository as the source code on which they operate on? Can pipelines live in their own branch or even in a dedicated repository without any functional impact on them (e.g. ci pipelines not getting triggered when source code is updated)? – Pelage

This is possible, however there is not needed. (please check repositories resources here. My idea was that you should do change on branch, not on the master. And there is better chance that you will have template in separate repo (than pipelines which build repos), because this is a great idea of sharing common stuff across all repos. Since you can apply DRY on repo level, you can move up to organization level and save efforts of keeping stuff in sync. – Cirri

To sum up if you don't see need to have pipeline on different repo than code which it builds, don't do that. But if you use the same code in template across repos please consider creating separate repo for template and use them in pipelines. – Cirri

Anyhow even having pipelines in their own branch or in a dedicated repo, template pipelines would still always be triggered whenever you update any yaml file including themselves. The only way I see to stop this is place some condition on stage/job execution. Weird situation. – Pelage

No. If you create separate branch and apply change in template in this separate branch (all you have in the same repo), this change only affect pipeline when triggers goes from that branch. Please check me edit. Does it explain to your issue? – Cirri

I understand what you just now explained. What however I'm trying to say and I'm not sure you got is that since a template pipeline does not allow specifying a trigger and thus even specifying an exclude statements, it will always trigger itself each and every time you update it. – Pelage

If you do not want to trigger pipeline just add [skip ci] in the git comment. – Cirri

Answer 6

There are no less than three spots in Azure DevOps that may be used to disable automatic build. Which one do you use to disable the irritating automatic builds that occur? Not sure

Firstly, Pipeline triggers as described here. I had to disable this to stop GitHub kicking off an automatic pipeline for PR's https://mcmap.net/q/327128/-azure-devops-how-to-disable-ci-trigger-on-a-yaml-template-pipeline

Confusingly this isn't in the immediate pipeline hamburger menu, it's under "Edit" then hamburger/triggers. As far as I can tell it doesn't change any source code but it does request a commit message. So much for YAML being the one true definition of deployment

Secondly, In Project/Settings there's a switch for "Disable implied YAML CI trigger".

Thridly, trigger: none in the YAML itself. This being the only actual area where your config is captured in Git

Inverson

Github? This post was on pipeline templates in Azure DevOps – Pelage

It doesn't matter what the Git provider is. The point is why is this auto build switch defined in three different spots, with only one of them actually source controlled. I have updated the answer to explicitly reference Azure DevOps – Inverson

Yep agree. I just think that properly decomissioning features is equally as important as adding features. It's easy to add a new feature. It's difficult to decomission old ones. It's even worse to hide the same feature in three different spots with onconsistent UI – Inverson

Your comment is certainly relevant. I suppose the explanation is that products evolve over time, meaning that you start providing one capability and then you improve and provide something better, something that achieves the same functional result but is somehow better (maybe more consistent with the overall product or just more aligned with technology evolution) but at that point to keep providing backward compatibility you need to leave in place both ways of achieving that result – Pelage