I am having difficulty in setting up my project for dev and release work. I have gone through various articles but I am unable to come to a definitive conclusion about how to setup up my dev and release pipelines for different branches. I need help in this area.
As an example, say I have a Dev branch with a pipeline DevPipeline in /azure-pipelines.yml.
This pipeline has CI triggers like so:
trigger:
Dev
features/*
Now, when I create a branch Release/R1.0 what exactly do I need to do?
Do I create a new pipeline say Release-R1.0. Where should the .yml for this pipeline be?
Should it overwrite /azure-pipelines.yml or should I create /Release-R1.0.yml?
If developers want to work on a fix/hotfix for R1.0, should they work under hotfix/R1.0 branch? In this case, I would have to adjust my triggers accordingly in the R1.0 yaml?
Any help is really appreciated.
Thanks
Now, when I create a branch Release/R1.0 what exactly do I need to do?
Do I create a new pipeline say Release-R1.0. Where should the .yml for this pipeline be?
It depends on whether your new created pipeline has the same build as the pipeline on the Dev branch. If yes, you can just add one more trigger Release/R1.0 in the azure-pipelines.yml:
trigger:
Dev
features/*
Release/R1.0
If they do not have the same pipeline, or you do not want use the same pipeline for the branch Release/R1.0, you need to create a new pipeline say Release-R1.0. And the .yml for this pipeline should be set the yaml file in R1.0 branch under the Release folder. Check my previous thread for some details.
Should it overwrite /azure-pipelines.yml or should I create
/Release-R1.0.yml?
Since they have different triggers or different build tasks, it should not overwrite /azure-pipelines.yml, you need create a new /Release-R1.0.yml.
If developers want to work on a fix/hotfix for R1.0, should they work
under hotfix/R1.0 branch? In this case, I would have to adjust my
triggers accordingly in the R1.0 yaml?
If I understand you correct, if you want to work on a hotfix for R1.0, it is better to create a branch Release/hotfix-R1.0 based on the R1.0, and in the R1.0 yaml, you could set the triggers:
trigger:
Release/*
So, you do not have to adjust my triggers accordingly in the R1.0 yaml.
Hope this helps.
Related
In Azure Devops, when i view a branch Repos->Branches->Select a branch i was able to click Set up build.
However, i am not able to choose an existing pipeline there.
When i select a pipeline Pipeline->Edit->Triggers i can add Branch filters aswell as path filters, however those do not take effect.
I tried to add filters for release/my-release aswell as release/* or a path-filter release.
I want to be able to start a pipeline from the Branch overview. What do i have to do?
If you're using YAML pipelines, e.g. azure-pipeline.yml, make sure this file is also available in your branch.
If the pipeline YAML was added to main after you've branched the release branches, the build will never trigger. Because the branch doesn't have the pipeline YAML .
Furthermore the triggers of the YAML should be specified in the YAML instead of Pipeline->Edit->Triggers.
Example:
trigger:
branches:
include:
- master
- release/*
Don't forget to turn off the "Override the YAML continuous integration trigger from here" Option:
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.
We are following gitflow model in our project using Azure DevOps Services. I have a classic editor based pipeline which builds the Dev and Release/R1.0 branch.
I am going to setup a classic editor based pipeline which will build my Release R.10 from the master branch after merging Release/R1.0 branch at the end of the release. Let us say this classic editor based build pipeline is MyProduct-R1.0
After the release, I will be tagging the master branch and deleting the Release/R1.0 branch as per GitFlow model. However, I will be retaining the build pipeline MyProduct-R1.0
My question is this: Suppose after the Release R1.0 once master branch has moved ahead and I want to do a build of master branch at R1.0 tag, how do I do using the MyProduct-R1.0 pipeline which was used to originally build the R1.0 release?
I know this is possibly a confusing question, but I have tried my best to give it a shot.
Thanks,
Update 2: I think my question is more about the branch specification for my MyProduct-R1.0 release pipeline. I can't give master since master will evolve after the Release R1.0. I can't give Release/R1.0 since this branch will be deleted after the Release as per gitflow model. So what branch specifications should I provide for my pipeline?
Use YAML builds. There's no mechanism for this with JSON ("classic editor") builds, since JSON builds are versioned separately from source code.
Like Daniel said YAML is the best path. Handles this gracefully as the Build definition lives with the branch.
In the past for GUI builds, when I dealt with build definition drift, instead of creating new build definitions, I would use conditional steps tied to the branch that was being built, but it can be painful to go back and update\maintain.
I think here is what will achieve what I am after. Once I do my release and tag it as R1.0, then I can always use my pipeline at a later date to build the same source code in the master branch for R1.0 using either it's tag or the commit it.
Note that this shows Dev is my default branch for this pipeline as it is not yet the Release pipeline which I depict below. I am yet to create it.
Am I missing something?
CI doesn't trigger when I change anything in my feature/* branch. I configured a YAML on Azure pipeline -
trigger:
branches:
include:
- feature/*
I also tried the other style of configuration - again unsuccessful
trigger:
- feature/*
Also tried with the complete feature name like feature/my-feature
However when I override the YAML trigger and use branch filters to point to the specific feature branch the CI works when I make changes in the branch.
I followed this official documentation
Azure Pipelines - CI Trigger on feature branch doest work with YAML
You should set the yaml file in one of branch under the feature folder.
Since you set the trigger with feature/*, but there is no branch named feature, we could not set the the yaml file in feature brance of the repo. So, we need to set the the yaml file in one of branch under the feature folder, like: feature/Test.
In this case, when I change anything in my feature/* branch, like feature/Test2, it will trigger this pipeline.
Hope this helps.
the one reason this could happen - the yaml file is not present in the feature branch. the decision to trigger the build or not comes when a commit is pushed to a branch, based on the content of the yaml file in the branch. if the file is not there, obviosuly nothing will be built.
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.