I have two Azure DevOps pipelines set up so that the completion of Pipeline One triggers Pipeline Two. It works fine, but it generates an unnecessary error message.
All recent Pipeline Two builds are listed on this page (not really a link, don't bother clicking on it) : https://dev.azure.com/mycompany/myproject/_build?definitionId=29
Any trigger issues are listed on this page (not really a link, don't bother clicking on it) : https://dev.azure.com/mycompany/myproject/_build?definitionId=29&view=triggerIssues
It appears that every run of Pipeline One -> Pipeline Two adds this warning to the Trigger Issues page: "Tags set for the trigger didn't match the pipeline". It's only a warning, not an error, and Pipeline Two executes successfully. But how can I eliminate this warning message?
The pipeline resource is specified in Pipeline Two as follows:
resources:
pipelines:
- pipeline: pipeline-one
source: mycompany.pipeline-one
# project: myproject # optional - only required if first pipeline is in a different project
trigger:
enabled: true
branches:
include:
- master
- develop
- release_*
No tags are specified, because tags are not used.
I have reviewed the following documentation without finding an answer. I may have missed something in the docs.
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/pipeline-triggers?view=azure-devops
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/resources?view=azure-devops&tabs=schema#define-a-pipelines-resource
https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/resources-pipelines-pipeline?view=azure-pipelines
I am using GitHub a
ctions to manage my CI and the following events trigger my workflow:
on:
pull_request:
branches: main
push:
branches: main
I observed the following "problem":
When I create a PR, the CI is run. If the test passes and I merge it into main, the tests are run again (which I don'
t want in specific cases). How can I setup my workflow such that the CI is not triggered when merging a PR, where the CI already passed for the PR?
Thanks in advance!
You might consider an if conditional in your case:
jobs.<job_id>.if
You can use the jobs.<job_id>.if conditional to prevent a job from running unless a condition is met. You can use any supported context and expression to create a conditional.
When you use expressions in an if conditional, you may omit the expression syntax (${{ }}) because GitHub automatically evaluates the if conditional as an expression. For more information, see "Expressions".
jobs:
build:
if: github.event.pull_request.merged == false
. . .
That would still trigger the workflow, but it can skip the jobs in the workflow.
Alternatives exist in this thread, which deals with the opposite requirements ("Trigger workflow only on pull request merge"): it can be adapted to do what you need (not trigger a workflow, or at least do the same job twice, on PR merge)
The GitHub Docs state the following:
For a pull_request event, only branches and tags on the base are evaluated.
As far as I am aware, the base parameter of a pull request cannot be a tag, but rather must be a branch. With this in mind, would a workflow that contains exclusively the following trigger:
on:
pull_request:
tags:
- '*'
ever actually run?
I'm trying to set up policies on my Azure DevOps Branches.
I'm able to state that a branch must build and pass our unit tests before allowing a merge but is there a way to restrict which branch is allowed to merge into it.
I have two branches that this would impact.
I have my 'master' branch that I would like to restrict to only accept pull requests from a branch called 'UAT'.
I have a branch called 'UAT' that I would like to restrict to only accept pull requests coming from a branch called 'Dev'.
The closest workaround I could think of is to have a very simple pipeline that would run on pull requests and check System.PullRequest.SourceBranch and System.PullRequest.TargetBranch. If the values don't match your policy, then fail the pipeline, which in turn will block the PR.
Based on the answer by qbik i created this short yaml code. Replace the source and target as needed for your use case. The code below is only for testing in my pipeline, to create the desired failure.
- powershell: >
if ("$(System.PullRequest.SourceBranch)" -ne "refs/heads/acc" -And "$(System.PullRequest.TargetBranch)" -eq "refs/heads/test")
{
Write-Error "
=========================================================================================================
Branch check failed.
Illegal Pull Request from $(System.PullRequest.SourceBranch) into $(System.PullRequest.TargetBranch).
========================================================================================================="
}
displayName: Branch Check
I am using Azure pipelines with a Github-based project. I have set up a build pipeline that is triggered only by tagged commits, to keep it separate from automatic daily builds that happen at every commit.
I would like to exclude tagged commits from triggering the daily build pipeline. What is the correct way to do so in a yaml script?
Here is what I did, without success.
According to Azure documentation at this page, to my understanding excluding tags should be possible with something like:
trigger:
tags:
exclude:
- projectname_v*
However, this does not work, and just prevents the build pipeline to run at any commit, be it tagged or not.
I have also tried:
trigger:
tags:
include:
- *
exclude:
- projectname_v*
but this is apparently not supported, as it produces error:
/azure-pipelines.yml: (Line: 12, Col: 7, Idx: 220) - (Line: 12, Col: 8, Idx: 221): While scanning an anchor or alias, did not find expected alphabetic or numeric character.
I have also tried the alternative syntax proposed on the doc page:
trigger:
branches:
exclude:
refs/tags/{projectname_v*}
as well as variants with/without braces and wildcards, but all fail with "unexpected value" or "Input string was not in a correct format" errors.
Edit 2019-12-10
After reading wallas-tg's answer below, I have tried the following in the daily build pipeline:
trigger:
branches:
include:
- '*'
exclude:
- 'refs/tags/*'
This works, but does not do what I would like:
Pushing only a tag triggers the correct pipeline and not the one for daily builds
Pushing a commit without tags triggers the daily build pipeline
Pushing a tagged commit triggers both pipelines: the daily build pipeline gets triggered by the commit, and the other one by the tag; my desired behavior in this case would be that the daily build pipeline is not triggered.
#acasta69
I think that i found solution for your issue. I've been doing just the opposite scenario, build only features branches and exclude anything else.
For this purposes use this yml snippet on azure-pipelines.yml
resources:
repositories:
- repository: myNetProject
type: GitHub
connection: myGitHubConnection
source: wkrea/DockerHubImages
trigger:
batch: true
branches:
include:
- releases/*
exclude:
- '*'
paths:
exclude:
- README.md
I was be able to build on DevOps from
If this answer was useful for you, let me know commenting and rate my answer to find it more easy next time that anyone need help, because the DevOps Pipelines documentations it's really unclear and confusing at moment :'(
Here you can see checks for my last commit on releases branch
The syntax for build pipeline triggers is documented on this page.
Regarding what is exposed in the question, a couple of details are worth highlighting:
There is a default implicit trigger that includes all branches and is overwritten by any user-defined trigger. Thus, it is not possible to specify a trigger that only excludes something: doing that would end up in nothing being included, and the trigger would never fire.
This explains why the first code snippet shown in the question does not trigger anything.
When you specify a trigger, it replaces the default implicit trigger, and only pushes to branches that are explicitly configured to be included will trigger a pipeline. Includes are processed first, and then excludes are removed from that list. If you specify an exclude but don't specify any includes, nothing will trigger.
The default implicit trigger looks like this (note the comment in last line, which explains the error produced by the second code snippet in the question):
trigger:
branches:
include:
- '*' # must quote since "*" is a YAML reserved character; we want a string
Summarizing, a correct way to do exclude tagged commits from triggering the pipeline should be the one shown in the edited part of the question:
trigger:
branches:
include:
- '*'
exclude:
- 'refs/tags/*'
Or, which is equivalent:
trigger:
branches:
include:
- '*'
tags:
exclude:
- '*'
However, this does not obtain the desired effect. The following happens instead:
Pushing a commit without tags triggers the pipeline
Pushing only a tag does not trigger the pipeline
Pushing a tagged commit still triggers the pipeline
A final feedback received from Azure DevOps support clarifies that there is no way at the moment to obtain the desired behaviour:
Basically there is no way right now to prevent builds from being triggered if the tags are committed along with the branch changes and the CI on branch changes are enabled on the pipeline. There are couple of options you can use to prevent triggering the build on new tags:
Check-in the tags separately than the branch changes.
Add "[skip ci]" to your commit message to skip triggering the build on that particular commit.
None of the two options fit well to the original request. #1 is already working as intended, i.e. it does not trigger the build unless tags are explicitly included in triggers, which is only a part of the original request. #2 has the desired behaviour, but it requires a specific commit text and would force any user of the pipeline to be aware of its internals.
The workaround that I found in the meantime, as mentioned in a comment, was to use only one pipeline, that is always triggered by any commit, whether tagged or not, and detect the use of tags with dedicated scripts to activate specific pipeline steps when required.