I have a ADO git repo with a YAML-based build pipeline that builds a docker image, runs some tests using Docker Compose, and then pushes the image and a helm chart to an ACR.
I'd like the have the build/test part run on PRs too. I have created a second pipeline that's just the first half of the normal build, and assigned it as a Build Validation pipeline for a branch.
However, I don't seem to be able to get the triggers right. If I have trigger: none in the test pipeline, it never triggers. If I have branch names, it is also run on merge alongside the normal build pipeline. How is this supposed to work? The docs define all the individual parts, but not really how they are expected to interact!
Am I supposed to have a multistage pipeline and use that somehow for the validation? (it's just 4 Steps in one Job in one Stage currently).
I am hoping to avoid building the same image too many times, or storing untested images anywhere outside the build agent.
I make it work with the following configuration:
In my YAML pipeline, I set the trigger: none.
In branch policies of a branch, I create a build validation with automatic trigger:
Then I create a pull request to that branch, and the pipeline runs automatically:
There are two possible mistakes:
The "Manual" trigger is selected in build validation, so that the pipeline needs to be run manually rather than triggered automatically.
The branch with branch policy set should be the same branch as the target branch of pull request.
Related
I have some Azure YAML pipelines that I need to trigger in a chain. I am finding that the documented approach does not seem to work. I have tried various things recommended in other SO posts: Azure Pipeline to trigger Pipeline using YAML and Azure DevOps unable to trigger yaml pipeline off of completed build.
I also know they had open bugs for some of this so not sure if I am missing something or if the feature is broken now?
For sake of brevity, I have two pipelines named "MyProject.Common" and "MyProject.Foo". I want Foo to run after Common succeeds.
A snippet of my yaml is below. Note that here are some things I have already tried:
Not including the first "trigger: none" line.
Including "trigger: true" after the "source:" bit, instead of the "branches: include:... piece".
Tried is with "branches: include: - '*' "
And various other things. MyProject.Foo is just not being triggered.
I have also verified that there are no CI triggers under the Edit -> Triggers menu.
Have also verifies that MyProject.Common is publishing a build artifact.
Any ideas? If this is a broken feature, what would be a good workaround?
Snippet:
trigger: none
resources:
pipelines:
- pipeline: 'MyProject.Common'
source: 'MyProject.Common'
trigger:
branches:
include:
- main
- refs/head/main
Branch triggers and Pipeline resource triggers are very similar but have one very big difference - how and where the trigger is evaluated.
Branch triggers get evaluated for every branch.
Pipeline resource triggers get evaluated ONLY On the pipeline Default branch.
from the docs:
Pipeline completion triggers use the Default branch for manual and scheduled builds setting to determine which branch's version of a YAML pipeline's branch filters to evaluate when determining whether to run a pipeline as the result of another pipeline completing. By default this setting points to the default branch of the repository.
source
What does this mean?
Your pipeline resource trigger yaml changes need to be in default branch of the pipeline that you want to be triggered. You can do this by merging your changes into the default branch, or changing the default branch to your dev/feature branch by following these instructions.
I am not at all sure why, but I deleted the dependent pipeline and created a new one (referencing the original yaml file) and it then triggered properly.
I can only guess that Azure lost some type of reference behind the scenes as the YAML for the trigger was accurate.
Thanks for all the input. It was helpful even though it didn't solve the main issue.
I've been fighting with this for a while. I've been able to get it working with two separate release pipelines, but not with one. It seems that in one pipeline the PR trigger for releases fires for all environments, even with separate build artifacts.
Goal is to have the following in one release pipeline:
PR to dev and merge to dev deploys to dev environment
PR to main deploys to QA environment
Merge to main of said PR releases to prod (with manual approval step).
It would be great to get this one one release pipeline, as that would reduce overhead and management, etc.
I've tried all sorts of variations with artifact release triggers and the environment pre-deployment conditions, but to no avail.
I've even tried using 2 separate build pipelines (one for main, one for develop) and then loading both as artifacts and trying to separate that way, but even when only 1 build pipeline runs, it triggers the PR release condition for both environments.
You should be able to achieve this if you implement your release pipeline with the new YAML pipelines.
The simplest option (which is not quite what you are asking for but should get the same outcome) would be to create a template with your core deployment logic, then create separate pipelines that reuse this template. That should allow you to replicate the triggers that you already had working for two release pipelines without needing to duplicate the deployment code.
Alternatively, you could set up a single YAML pipeline with Stages for Dev, QA and Prod, and set conditions on the stages, based on the source branch and/or build reason.
I have repository on local GitLab server of my organization and want to trigger build pipeline that then will trigger release pipeline and publish to staging/production VMs.
I've read a lot of articles at microsoft docs, SO and tons of blogs that you can trigger pipeline by tags providing branch filter like refs/tags/v*. YAML configuration has additional section special for tags, however YAML is not supported for git repos that are connected as "Other git".
And that tag trigger just never works. After I set up trigger UI shows me just "v*", so it understands that refs/tags has special meaning. I can run pipeline manually specifying exact tag, like refs/tags/v1.0-test, and it works. But never launches automatically. Branch triggers work without problems.
What I've already tried:
set include filter for refs/tags/v* - doesn't work
set include filter for refs/tags/exacttagname - doesn't work
set include filter for refs/tags/v* and another one for master - triggers only for master
set include filter for refs/tags/v*, for * and exclude filters for refs/heads/* and refs/remotes/* - doesn't work
I tried pushing commit, then pushing tag. Tried pushing commit and tag in one requiest with git push ---follow-tags. Tried pushing tags for older commits. Nothing of that works.
This issue about the same problem was resolved on azure side previous summer, however all comments where about GitHub integrations. So maybe it's still broken for "other git" or smth else.
Any help?
I tested and got the same result, tags triggers for other git doesnot work. You can submit a feature request(click suggest a feature and choose Azure devops) for supporting tag triggers for gitlab repo to Micrsoft Development team. Please check this thread for example.
As workaround you can use multiple agent jobs to achieve above currently.
You can add another agent job before your original agent job to run a script task, And add dependency on it in your original agent job. The script task will check if there is tag associated to the current commit. If the tag exits, the script task will pass, and the following agent job will run. Or the script task fails and the following agent job will be skipped.
The detailed steps is as below:
add a agent job with a single powershell task. Check below screenshot.
Run below inline scripts in the powershell task to check the tags
$tags = git describe --tags $(Build.SourceVersion)
if($($tags) -notmatch 'v.'){exit 1} #fail the task if the tag doesnot match v*
In the original agent job, add dependencies to above agent job.
Go to Triggers tab and filter all branches.
I have four environments that I deploy to.
I also have four different code branches that we use to deploy code from.
We constantly switch the branches we use to deploy on these environments.
One time I want to build and deploy a daily branch on my test environment.
Later I want to build and deploy a enhancements branch on the same test environment.
Next I want to build and deploy the daily branch on my test2 environment.
I think you get the picture
We are currently using a manual process to pull from the branch we want deployed, then zip it up and push it to AWS code deploy.
Using Azure DevOps pipeline and release what is the easiest method to allow me to switch to use different branchs on different environments.
I currently have a successful setup in Azure DevOps that performs a gradle build, creates the artifact and then lets me push it over to AWS CodeDeploy on one of my environments. I just can't seem to figure out a way to eastily swtich the branch without creating tons of Azure pipelines and releases.
Thanks all!
Where you manually trigger a build pipeline by clicking Queue or Run Pipeline, A new windows shown as below will be prompted which allows you to switch the branches.
If you want to automatically deploy different branch to different environment. You can push the build artifacts over to AWS CodeDeploy in a release pipeline and set the branch filters. Please refer to below steps:
1, set branch filter in the build pipeline as shown in below screenshot which will build the selected branched. Check here for more information about triggers.
2, create a release pipline to push build artifacts over to AWS CodeDeploy.
And Set the Artifact filters which will only allow the artifacts built from the specified branch to be deployed to this tage.
You could use a queue time variable to specify the branch name you would like to use on your build pipeline. You would need to:
Edit your build pipeline and create the variable on the "variables" tab. Make sure to mark the "Settable at queue time" check
variable creation
Update the source of your build pipeline, to specify the new variable under the "Default branch" option. It would look something like this:
pipeline source
RUN your pipeline. Before finally clicking on RUN, you will be able to specify the desire branch:
set variable value
Hope this works
We often want to test the first part of our release pipeline using a code from the branch. While I can easily trigger the build from any branch, not so with the release pipeline - I have no idea how to trigger it from anything else other than the branch specified in it.
So far my solution was to temporary clone the pipeline, redirect to another branch and use it while testing. Then delete it.
But I wonder if there is a better way. We use TFS 2018 (on-premises), so no YAML to show here.
This is how our pipeline looks like:
When I click the Source I get:
And the Continuous Deployment Trigger on the Source:
Now clicking the Build Artifact:
And the CD trigger:
The four smoketest5x are the same. They have two tasks (a ps1 script and to publish the test results) and their triggers are:
Pre-Deployment:
Post-Deployment:
Finally, the Production stage. Its pre-deployment trigger is the most interesting:
And there is manual approval.
It does not seem possible to provide the branch at release creation time, but maybe I am missing something here?
You can't specify a branch at release time. If you need to do that, create a build pipeline that publishes an artifact, then release a build. You can choose builds versions at deployment time.