I have a Question about the Pipline trigger in Devops.
My team and I are using Azure Devops to develop a software.
We use a Branch Specific trigger, to start the pipeline only in out Master Branch. The other branches are ignored in the YAML File.
First part of my question is, that we don't know a way how to trigger the Pipeline over a commit message in our Git tool.
For example: "We work in a different branch than the Master branch -->No Pipeline is running. But we want to trigger the pipeline in this Branch for a Specific test just one time. Our way would be to insert a specific command in the commit text to trigger the pipeline."
My second question is, if it's possible to run different stages in different Branches in one YAML file.
Here again an example: " In our different Branch, we just want to run our unit tests every push. In our Master Branch we want to run our unit tests and after that, we want to build our application.
So far, we started the pipeline at every push and build a new image everytime. But we dont want that, because some pushs arent working and we just push it. We want to decide when the pipeline is running and whitch stage is running.
I hope you can understand my problem. For further questions, please comment here.
Thanks
Question 1:
You can consider using tag triggers to do this. Here is an example:
trigger:
branches:
include:
- master
tags:
include:
- test.*
Then the pipeline will be triggered when working on the master branch or the commit tag is test.*.
Question 2:
You can use conditions. Here is an example:
condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))
Add the condition to your stage, and then the stage will be only triggered by the master branch.
Question 3:
So far, we started the pipeline at every push and build a new image everytime. But we dont want that, because some pushes aren't working and we just push it.
You can skip CI for individual commits.
Just include [skip ci] in the commit message or description of the
HEAD commit and Azure Pipelines will skip running CI.
Update 1:
For Question 1, the test.* means a tag which started with test., such as test.1, test.0.1, and so on. You can change the test.* to anything you want.
As for the question your encountered, you can't create a tag called test.* directly because a tag name cannot contain *.
To avoid confusion, you need to create a tag for the commit to trigger the tag CI, rather than writing it directly in the commit text.
The idea
insert a specific command in the commit text to trigger the pipeline.
I don't think is currently supported and tag trigger is an alternative.
Click this document for detailed information about git tag.
Update 2:
Trigger the stage by master branch or 1620-to-PipelineTrigger branch:
condition: or(eq(variables['Build.SourceBranch'], 'refs/heads/main'), eq(variables['Build.SourceBranch'], 'refs/heads/1620-to-PipelineTrigger'))
You can set only one condition per stage, but you can create more complex conditions using and, or and ().
Click this document to get more detailed information and examples about conditions.
Related
I have created a simple readme file in the main repository. Now for example if someone creates a feature branch out of the main branch and edits the readme file. Those commits will be then committed in the feature branch.
Now I want to create a pipeline which should do the following:-
Whenever there is a push in the repo it should run the pipeline automatically.
The pipeline should check that every NEW content to the README.md has to have at least a one time mentioning of words like "ABQ" OR "abq" OR "albuquerque" OR "Albuquerque".
So basically The push based pipeline shall check if the added text in the feature branch does at least have one occurrence of the above mentioned words.
Here is the yml file i have that runs whenever there is a push. Can someone guide me here for achieving the above goal?
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "push"
when: always
How do we create multi branch pipeline in azure.
Say there are 4 developers committing to the same branch, for each commit there should be a seperate build pipeline with unit tests.
for each commit there should be a seperate build pipeline with unit tests.
If you want to have a seperate build pipeline with unit tests for each commit, you need to create multi pipeline for each branch:
And if just want to one build pipeline for those multi branch, you may need to have create multi branch triggers:
I think what you need is a CI pipeline. So lets say, there is a main/master branch, 4 developers have pulled this main branch in their PC/laptop. And all 4 of them are about to work on 4 different defects/bugs say bug1,Bug2, Bug3 and Bug4
Each one of them are supposed to create a branch from main. Say bug/Bug1, bug/Bug2, bug/Bug3 and bug/Bug4. So now we got 4 branches.
What you can do now is switch on pull request branch policies in main branch. Please see below screenshot
Once you switch on this pull request policy, no code can be merged in your main branch without creating a pull request.
Now second part, you have to create a pipeline that will for example, build the code and run some tests.
Now part three: In the same branch policies page, if you scroll down a bit, you will see a setting for "Build Validation" as shown below
What you have to do here is
Press that + sign and configure the pipeline that you have created earlier here.
What this means is
When say Dev 1 whose branch is bug/Bug1 will raise a pull request to merge in main branch, this Build validation will trigger the pipeline that you have configured here.
So when all 4 Devs will raise 4 pull requests, based on their code changes, this pipeline will get triggered and validate those code changes for build + tests.
Also, based on the code review, if there are any further code changes pushed into these branches (bug/Bug1 etc.), you can configure this Build validation in such a way that this pipeline will get automatically triggered whenever new code changes are pushed into a branch which is connected to a pull request.
I have created a pipeline in my repository which is used to validate code by executing unit tests for code that is being pushed to features/* branches. The same pipeline is used as Build validation pipeline set as Branch Policy on the develop branch to validate incoming PRs. This is the trigger of the pipeline.
# pipeline.yml
trigger:
batch: false
branches:
include:
- features/*
However we have come across the following condition: Given an open PR from refs/heads/features/azure-pipelines -> refs/heads/develop we push a commit on the features/azure-pipelines branch.
This causes the pipeline to trigger twice. To my understanding one of the runs is due to the trigger of the pipeline (The one marked as Individual CI on the screenshot) and the second run is due to branch policy trying to validate code being pushed onto the open PR to develop. (The PR Automated)
Is there any way to disable one of the executions since it's essentially a duplicate? I was maybe looking for a way to retrieve open PRs and abort execution of a pipeline for Individual CI if there is an open PR for a branch but I am not sure that's the best way around that and I am looking for options.
You can set
trigger: none
This way only the branch policy will trigger the pipeline.
Is there any way to disable one of the executions since it's essentially a duplicate?
As we know, we could not disable the Build validation pipeline set as Branch Policy on the develop branch to validate incoming PRs unless we cancel the Build validation.
For your situation, you could try to include [skip ci] in the commit message or description of the HEAD commit to make the Azure Pipelines skip running CI when you plan to merge the features branch to the develop branch.
You could check the document Skipping CI for individual commits for some more details.
Here it depends if they does the same. You can have conditional checks in the pipeline which does a different things for PR and CI runs. However, I'm pretty sure that this is not possible, because one is defined on the YAML and the second on the Azure DevOps portal. So even if you disnle PR trigger here in YAML, a branch policy still runs a PR. And you can specify antyhing in YAML to block branch policy.
I have my repository on GitHub and my CI/CD pipelines on Azure DevOps. What I want to achieve is, that once a PR merges onto the master branch that the pipeline deploys. No PR creation should trigger the pipeline. Unfortunately I can't seem to get the trigger right.
My trigger looks like this:
trigger:
branches:
include:
- master
pr: none
When I push changes onto the master branch, the pipeline gets triggered. But if I do it via GitHub PR, nothing happens. I also tried it with release pipelines but I seem to have the same problem there. Any pointers in the right direction would be much appreciated!
I'd suggest just use trigger for CI
trigger:
branches:
include:
- master
Omit the pr section.
This would then run your pipeline whenever you make a PR to master as well as once you complete the PR.
And now to prevent the pipeline from running whenever you make the PR and only once you complete the PR to master, use a condition on your build stage
- stage: 'Build'
displayName: 'Build my application'
condition: eq(variables['Build.SourceBranchName'], 'master')
jobs:
etc.....
I have figured it out. Something is completely off in my repository. No idea how I managed that, since I thought that should not even be possible.
Anyway, I tried the triggers with an empty repository and it works like a charm.
I had a similar thing with Pull-Requests from Github. In the end i just used the old school "triggers" section and it started working.
Just edit the pipeline and in the "..." drop down selected triggers and then go to the "Pull Request Validation" row and enable it. Lastly pick the target branch.
Note: sometimes is can take a few minutes for DevOps to pick it up.
My Azure DevOps pipeline has 3 jobs. One builds the project for production and the other builds it for testing and the last publish artifacts. When I push to release branch, it triggers all of 3 jobs, but they can take 10-15 minutes to finish. What I'm trying to achieve is exclude testing job if a tag is present on the commit or something like that.
Ex. Don't trigger test job if branch tag has "hotfix". Tryed "Run this job with conditions" in job's settings with this value "not(startsWith(variables['Build.SourceBranch'], 'refs/tags/hotfix'))" but if I push something to release with hotfix tag it still runs.
Thanks
We recommend you can use the conditions:
condition: eq(variables['Build.SourceBranch'], 'refs/tags/test')
And this means if you want the test job to run, then you need to push something to release with test tag. We cannot use the value "not(startsWith(variables['Build.SourceBranch'], 'refs/tags/hotfix'))"
On my test, if I push the commit release with hotfix tag, then the test job will be skipped.
Update:
We can use the Custom conditions in Additional options, and set it as :
eq(variables['Build.SourceBranch'], 'refs/tags/test')
More details, you can refer this doc: Expressions