I have multiple artifacts for each branch. Continuous deployment trigger is enabled For Dev: _CI_Dev For QA: _CI_QA For Staging: _CI_RC
I want to setup a common stage (since the tasks are same across environments) which should identify the source branch and use corresponding artifacts.
How to add approval and gates only for QA and staging?
How do I identify the source branch which triggered the tasks (for a job)? Should I run a powershell script to setup source branch value in variable to be used in tasks?
How to add approval and gates only for QA and staging? How do I identify the source branch which triggered the tasks (for a job)? Should I run a powershell script to setup source branch value in variable to be used in tasks?
I am afraid we could not add approval and gates only for QA and staging, if we want enable Continuous deployment trigger for all artifact sources.
That because approval and gates currently do not have separate filters, they rely on the option Artifact filters:
However, if we set the Artifact filters for QA and staging, it will filter out builds from Dev: _CI_Dev. Obviously this is not in line with our expectations.
To resolve this issue, the easiest way is to clone the current stage (Although it can't exactly what you originally expected to use one stage, this is currently the best solution.), it will also clone all tasks in that stage. changing Select trigger from stage to release and set the Artifact filters for QA and staging:
Note: Do not forget to add Artifact filters for Dev: _CI_Dev to the previous stage.
Related
I have a Release pipeline with three environments. I have a single build pipeline (_TestCM) that builds different branches (develop, Master, release). All branch builds are CI builds.
I applied an artifact filter to each environment.
I want to deploy
Develop branch --> Environment 1 at 11:30 AM, 3 PM daily
Master branch --> Environment 2 at 5 AM, 7 PM daily
Release branch --> Environment 3 at 6 AM, 2 PM daily.
How can I configure the above scheduling requirement in a single release pipeline? Creating multiple release pipelines with single environment in each pipeline is not an option as we have hundreds of release pipelines. Release pipeline need to trigger at the scheduled time only if there are any changes from that branch.
If it is not possible in a single Release pipeline, what are the options we have for accomplishing this task considering the hundreds of Release pipelines?
Based on your requirement, I am afraid that it is not possible in a single release pipeline.
Release pipeline need to trigger at scheduled time only if there any changes from that branch.
For this requirement, there is an Option in Release Pipeline(
Only schedule releases if the source or pipeline has changed).
According to your deploy process, you need to determine the environment via the branches. So you need to add multiple artifacts for multiple branches.
In this case, this option will not meet your needs. It treats all atifacts as a whole. When one of the branches changes, the release will be triggered by the schedule and all artifacts of different branches will be deployed at the same time.
You can achieve your needs by creating multiple pipelines.
The following are the settings you can refer to：
When you add artifacts, you can select the branch and enable the option:Only schedule releases if the source or pipeline has changed.
For example:
In environemnt, you can directly set schedule trigger without other settings.
You need to create the corresponding number of release pipelines according to your branches.
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 a .Net project that uses the Azure DevOps pipelines. The setup is that I have a build pipeline that creates an artifact. The artifact then automatically gets published through the release pipeline. This is working perfectly.
The problem is after I turned on the policy Build Validation, pull requests now triggers the build pipeline which then triggers the release pipeline. So every pull requests gets published. The build step is correct, but the release should not happen. The pre-deployment trigger "Pull request deployment" is disabled.
What I did to try to solve this is that I added a condition to the build step where the artifact gets created. So pull requests does not create artifacts, while merges does. This also works as intended. However, the release pipe still gets triggered, but this time without an artifact (which fails the pipe).
TLDR:
Release pipe triggers on pull requests, settings for this behavior is off. WTD?
My CI/CD settings:
Your release triggers on any of your builds and branches (PR also has a branch). You have to add the branch filter: Continuous deployment triggers. Restrict your filter with the master branch or any other. Also, you can define 2 build definitions:
A pipeline to validate your pull requests without linked releases.
CI pipeline that triggers a release.
Additionally, I think, this is a bug. Because the PR trigger is not enabled. Let's check dev community comments: https://developercommunity.visualstudio.com/content/problem/1292039/release-pipelines-ignore-pull-request-settings.html
What we have here is that we've set up build pipelines tied to YAML files stored in the repository, together with source code. And release pipelines have their Source set up to each of the build pipelines.
This is part of the Master Build:
trigger:
batch: false
branches:
include:
- master
And this is part of the Pull Request Build:
trigger: none
pr:
- master
We have Release pipelines for each of the Source builds, having Pull Request triggers enabled in one of them only, but you can have only one for your master artifacts, so PRs won't be published.
Say you have a build and its corresponding release definition on Azure Devops.
Generally, the way it's used is like:
Repository "A" changes -> Build repo "A" -> Release to a given environment
Within this scenario (using only one build artifact), it's easy to trigger deployments (after successful build) for different branches.
But, say you also have a release definition with multiple build artifacts (from different repos), and you want to, changes coming from branch "dev" you want to deploy to environment "Development", but if changes come from branch "hotfix" you want to deploy to environment "Staging".
Something like this
You can play with branch filters on the specific environment and artifact filters on the artifact triggers.
The above scenario works very well for "dev" changes when you define your build artifacts to use "dev" as default branch.
But if you make changes on Repo A (branch hotfix), but not in Repo B, the build artifacts for that release will come from different branches, hence the "artifacts will not meet requirements", cause all changes must come from hotfix branch in order to trigger the deployment.
In my opinion, the "Default Version" of the Build Artifact itself, makes this confusion for the pipeline.
See this image example
That being said, how can we trigger a deployment into "Staging" environment if only one of the triggered changes come from the branch "hotfix" ?
The way I can see, when that happens, "Staging" environment never "meets the artifacts requirements", cause other artifacts will use version from "dev" as it's the default source branch.
Has anyone worked with a similar scenario ?
Thanks for reading my question.
Update:
According to your scenario, the best solution at present is to create two release pipelines to deploy separately, because Artifact A and Artifact B have no dependencies.
In the Continuous deployment trigger of the build artifact, you can set Build branch filters to include the dev and hotfix branches.
Then enable Artifact filters in the Pre-deployment conditions of the stage to set the build branch artifact conditions that trigger the deployment.
Artifact filters: Select artifact condition(s) to trigger a new deployment. A release will be deployed to this stage only if all artifact conditions match.
A build pipeline can be tied to only 1 source branch.
In release pipeline, we configure an artifact by selecting the source build pipeline. So a release artifact can be tied to only 1 build pipeline.
What is the purpose of Build branch filters in Continuous deployment trigger?
Let say that your code base was updated. You want deploy only if build was made over specific branch (example develop).
In that scenario Build Branch Filter looks fairly redundant... but what if:
You want to trigger new deployment for every latest artifact, built from each feature branch to get them tested. You have to filter for feature/*.
You want to trigger new deployments if your release branches are updated, but some of them are deprecated and you need to filter them out. I that scenario specify one include filter release/* and second exclude filter release/old*.
Anyway.. in most of the cases the filter and the branch name (in artifact) will match each other. Still sometimes it can be heady to trigger deployment from multiple branches or filter something out.
In regards to your comment, I uploaded part of the yaml build. In fact one build can create artifacts from all branches in repository if you want.
trigger:
branches:
include:
- feature/*
- bugfix/*
- release/*
- develop
- master
exclude:
- experimental/*