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.
Related
I am building a DevOps pipeline through yaml file which triggers a build for PR. Structure below:
pr:
- dev2
stages:
- stage: PR
condition: and(eq(variables['Build.Reason'], 'PullRequest')
displayName: prBuild
jobs:
- job: DowndSecureFile
if i raise a PR for the first time to the dev2 branch from another branch ex: dev3 it triggers.
Another build fails to trigger in this case:
If the PR is not yet merged:
and I have made additional commit to dev3 then build is skipped for the PR
I understand this is due to this condition where Build.Reason changes to CI:
condition: eq(variables['Build.Reason'], 'PullRequest')
But I am trying to do, that if a pr is still open and if i put additional commits to the PR branch dev3, i need to trigger a build again for that PR. Is there any suitable condition for that? or
Update:
I am using github enterprise, for the repository, no Azure Repos is used here.
should i do something else?
Can anyone help me here? Thanks.
The Build.Reason variable have a value of PullRequest when the build is triggered by a branch policy as indicated in the docs
This documentation shows how you can setup build validation as a part of your branch policy. The branch policy helps ensure the PR can only be merged if the build is succesful and also require a minimum number of code reviewers.
The manual describes that a new build is triggered for each updated commit to the pull request.
#Roderick Bant has given the doc for Build.Reason.On the base of his answer, i want to make additional information.
If you want to trigger a build for both PR and CI, you can modify your condition:
condition: and(succeeded(), in(variables['Build.Reason'], 'PullRequest', 'IndividualCI'))
I have a pipeline in Azure DevOps that is triggering from more than just the branch I have specified in the yaml file. I am using bitbucket cloud for my repository.
At first I had the trigger set like this:
trigger:
- development
Then I changed it to this:
trigger:
branches:
include:
- development
It is still triggering from 2 other branches besides development. When I look at the branches tab on the pipeline it has development and the other 2 branches it's triggering from. I also don't have any triggers set in the UI.
Any ideas? Thanks.
Have you updated the YAML file in the correct branch? The branch the pipeline definition is derived from?
As a workaround you could try to add the excludes clause in your YAML trigger to ignore those other two branches.
trigger:
branches:
include:
- development
exclude:
- PBI123
- PBI456
A note on the Branches tab, this is a summary of the pipeline runs that have already been executed, it is not a listing of the branches what will be executed by the pipeline.
I hope this helps resolve your issue.
Ok after looking into it some more I believe this solves it:
pr: none
As long as the PR has that in it. It shouldn't trigger.
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.
I'm having problems triggering a pipeline from another Pipeline in Azure DevOps. I have a CI pipeline and I want to trigger a Deploy Pipeline whenever CI passes on a master branch. This seems to be technically possible, but the documentation is unclear.
I see the following:
# this is being defined in app-ci pipeline
resources:
pipelines:
- pipeline: securitylib
source: security-lib-ci
trigger:
branches:
- releases/*
- master
But it's unclear as to a) whether this goes in the triggering pipeline (in my case the CI pipeline) or the triggered pipeline (in my case, the deploy pipeline).
It's also unclear as to what the pipeline and source refer to, and how I find out these variables? Are they both the name of the pipeline? I've tried various different permutations and nothing seems to be working.
EDIT 2
Finally Microsoft has improved their documentation with regards to the pipeline triggers in YAML! Here's the link.
EDIT
After having written my answer, Microsoft has come up with another solution to solve this problem, by using a build completion trigger via a classic pipeline. Their solution can be found here.
If you're not publishing an artifact from the triggering pipeline, it won't trigger the triggered pipeline.
Also, there is a very big restriction on the use of these types of triggers. It is necessary to change the defaultBranch for manual and scheduled builds in the depends pipeline, to the working branch. Otherwise it won't kick in at the end of the source pipeline execution. So, let's say you're working on feature branch, and defaultBranch is set to feature. You commit your code, and everything will run as expected: the source pipeline kicks in, and at its end, the depends pipeline will be triggered. All good! But when you will merge into master, if you do not change the defaultBranch, the depends pipeline won't be triggered at the end of the source pipeline. I explain how to change the defaultBranch at the end of the answer.
How to setup a pipeline trigger
I managed to get this up and running on a minimalistic project. Here you can have the code and here the project on Azure DevOps. I will try to guide you through how I did it, and answer the questions you've asked in your post.
I will be calling the triggered pipeline as depends pipeline and the triggering pipeline as source pipeline.
On the source pipeline, there's no need to do anything except publishing an artifact. If you don't publish an artifact from the source pipeline, it won't work. Below you can find the code I am using for my dummy source pipeline. I want it to be triggered for master branch, and at the end I want to be sure to publish an artifact.
trigger:
branches:
include: # branch names which will trigger a build
- master
pr: none
steps:
# required to cause pipeline triggering downstream
- task: CopyFiles#2
inputs:
contents: $(System.DefaultWorkingDirectory)/**/*.yml
targetFolder: $(Build.ArtifactStagingDirectory)
- task: PublishBuildArtifacts#1
inputs:
pathtoPublish: $(Build.ArtifactStagingDirectory)
artifactName: dummy-$(Build.BuildId)
On the depends pipeline (code shown below), I have to disable CI and PR triggers, otherwise when I commit to this repo, this pipeline will be triggered by the CI trigger, and then by the end of the execution of the source pipeline. This is done by the two first lines of my code. Then I want that the pipeline named source (this is the source property in the YAML below), within the project named Pipelining (project property in the YAML) will trigger the current (depends) pipeline when this updates master branch.
trigger: none
pr: none
resources:
pipelines:
- pipeline: source
project: Pipelining
source: source
trigger:
branches:
include:
- master
steps:
- checkout: none
- script: echo 'triggered depends'
Does it make sense? It is important for your project name on Azure DevOps to match the property in the YAML depends pipeline code.For me it is Pipelining
As well as the source property, again in the YAML depends pipeline code.
Change the default branch
In order to change the defaultBranch, because of the issue mentioned above, you should edit the pipeline (in this case, the depends pipeline), then on the three dots on the top right corner pick Triggers. Then choose the YAML tab, and you will get to the screen shown in the image below, where you can set the working branch.
Above yaml pipeline trigger should be defined in the triggered pipeline(deploy pipeline).
- pipeline: string the string here is identifier you give to this pipeline resource. It can any string.
source: string the string here is the definition name of the triggering pipeline(the name of your CI pipeline).
Below yaml is from the document pipeline resource.
resources:
pipelines:
- pipeline: string # identifier for the pipeline resource
project: string # project for the build pipeline; optional input for current project
source: string # source pipeline definition name
branch: string # branch to pick the artifact, optional; defaults to all branches
version: string # pipeline run number to pick artifact, optional; defaults to last successfully completed run
trigger: # optional; triggers are not enabled by default.
branches:
include: [string] # branches to consider the trigger events, optional; defaults to all branches.
exclude: [string] # branches to discard the trigger events, optional; defaults to none.
Option: You can also set the pipeline triggers from Ui page. Go the edit page of the triggered yaml pipeline(Deploy pipeline), Click the 3dots and choose Triggers
Go to Triggers--> Build completion and click add--> Select your triggering pipeline(CI pipeline)
Update:
I saw the pipeline resource in azure-deploy.yml is defined as below.
resources:
pipelines:
- pipeline: 'Deploy to Development'
source: 'DFE-Digital.dfe-teachers-payment-service'
trigger:
branches:
include:
- "master"
- "release-stuff"
please try changing the indentation of trigger element the same as source element. Check below example:
resources:
pipelines:
- pipeline: 'Deploy to Development'
source: 'DFE-Digital.dfe-teachers-payment-service'
trigger:
branches:
include:
- "master"
- "release-stuff"
I found the following:
In source pipeline I didn't need to create an artifact
In depends pipeline if I wanted to build after any commit to the source branch I could get it to work with this:
trigger: none
pr: none
resources:
pipelines:
- pipeline: 'depends'
source: 'common-gulp-trigger'
trigger: true
I may assume you are not working on the master branch, right? I have the same issue previously. But after I read the section Default branch for triggers of MS's doc. I understand why. The trigger only examine master's branch's yaml file by default. This means the pipeline will only be triggered by the definition of triggers in master branch's yaml file.
Therefore, whatever branches you add in the trigger section of yaml file in other branches(not master), tirgger is not active. You need to change the pipeline to look the yaml file in your current branch, not master. Just follow the doc's instruction, change the default trigger branch. You will get it working.
Once you merge your work into master, you probably need to change the dedault trigger branch back to master.
I'd can't seem to find any documentation of manual staging in Gitlab CI in version 8.9. How do I do a manual stage such as "Deploy to Test"?
I'd like Gitlab CI to deploy a successful RPM to dev, and then once I've reviewed it, push to Test, and from there generate a release. Is this possible with Gitlab CI currently?
You can set tasks to be manual by using when: manual in the job (documentation).
So for example, if you want to want the deployment to happen at every push but give the option to manually tear down the infrastructure, this is how you would do it:
stages:
- deploy
- destroy
deploy:
stage: deploy
script:
- [STEPS TO DEPLOY]
destroy:
stage: destroy
script:
- [STEPS TO DESTROY]
when: manual
With the above config, if you go to the GitLab project > Pipelines, you should see a play button next to the last commit. When you click the play button you can see the destroy option.
Update: Manual actions were Introduced in GitLab 8.10. From the manual "Manual actions are a special type of job that are not executed automatically; they need to be explicitly started by a user. Manual actions can be started from pipeline, build, environment, and deployment views. You can execute the same manual action multiple times." An example usage of manual actions is deployment to production. The rest of this answer applies to Gitlab 8.9 and older only.
Historical Answer:
It does not appear as though manual deploy/release was available in Gitlab in 8.9.
One possibility is to have a protected branch which triggers a release. See info about protected branches here: http://doc.gitlab.com/ce/workflow/protected_branches.html
Essentially a protected branch would allow you to Create a branch (testdeploybranch) which only you would be allowed to merge code into. Whenever a commit to dev would pass the Gitlab CI tests and deploy jobs, as well as your manual review, you could merge that commit into the protected branch to trigger the release. For this branch you can then set up a special release job in Gitlab CI using the only option in the .gitlab-ci.yml job definition. Read more here: http://doc.gitlab.com/ci/yaml/README.html
So something like this:
release:
only: testdeploybranch
type: release
script: some command or script invocation to deploy to Test
This might not be exactly what you are after, but it does allow you to do manual releases from Gitlab. It does not provide an easy way to manually do the same release procedure manually for different servers. Perhaps someone else might be able to expand on this strategy.
Finally, we have Gitlab CI manual actions that were introduced in GitLab 8.10.