I have two build definitions in Azure DevOps, one for gated check in and one for continuous integration into release. I want to use one build definition to run our GCI and our CI build so I don't have to maintain two separate build defs with similar setup, teardown, etc.
Is there a variable I can check in Azure DevOps when a build is queued to differentiate whether the build is triggered by a PR for GCI, or not? If there's a better way all ears.
Yes! there is a variable Build.Reason:
IndividualCI: Continuous integration (CI) triggered by a Git push or a TFVC check-in.
BatchedCI: Continuous integration (CI) triggered by a Git push or a TFVC check-in, and the Batch changes was selected.
CheckInShelveset: Gated check-in trigger.
So you can in the build task add a condition to run only of the build is GCI/CI, for example (run only if the build is CI):
and(succeeded(), in(variables['Build.Reason'], 'IndividualCI', 'BatchedCI'))
I think you can use predefined variable named Build.Reason.
Add it to Build number format and then whenever you trigger your build, you can see directly what triggers it in the build#.
For example, if your Build number format is $(date:yyyyMMdd)$(Build.Reason), then your build# will display 20190523PullRequest or other format that conform to the definition of variables.
I hope this will help you, have a good day.
Related
I have a continuously triggered Azure DevOps release definition that deploys a compiled Angular app to a web server and also runs Cypress e2e tests. The Cypress tests must run against the source code, so that means I need an artifact that is able to reference the same commit that was used to create the compiled app.
I created a GitHub artifact that gets the source code, but I can't figure out how to automatically change the branch/commit to whatever was used for the compiled app (it could be any branch and the names are not known ahead of time). Azure forces me to enter a hard-coded branch name and it does not accept wildcards or variables.
If I could simply use the variable ${Release.Artifacts.{alias}.SourceBranchName} for the default branch, I think I'd achieve my goal. Since Azure doesn't allow this, is there an alternative approach that accomplishes the same thing?
Note 1: The "Default version" dropdown has an option "Specify at the time of release creation", but that is intended for manual releases and can't be used for triggered ones, so no luck there.
Note 2: I looked into publishing the source code as an artifact, but it currently has almost 70,000 files and it adds more than an hour to the build step, so that also is not an option.
When you use the Release Pipeline artifacts, you are not able to set the pipeline variable in the Default branch field. This field only supports hard-coded.
is there an alternative approach that accomplishes the same thing?
The variable:$(Release.Artifacts.{alias}.SourceBranchName) can be used in the Release Pipeline agent job.
Workaround:
You can remove the Github artifacts and then add a Command Line task/PowerShell task/ Bash task to run the git command to clone the target repo.
For example:
git clone -b $(Release.Artifacts.{alias}.SourceBranchName) GithubRepoURL
PowerShell sample:
In this case, the script will use the same branch as Build Artifacts to checkout the source code.
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
Azure DevOps release pipelines let me specify multiple input artifacts but automated triggering only happens for the primary artifact. Is there a way to do a 'wait all' type operation on N input artifacts so that my release pipeline only starts when each artifact has a version available that matches some specified value?
For instance, say I make a commit M in a repo which has multiple different CI jobs A and B which take very different amounts of time. One CI job (A) creates a NuGet package as an artifact in minutes, the other CI job (B) takes hours to create VM images. I want a release pipeline which will use the NuGet package and VM image as inputs. But if I simply use the latest version of A and B as an input artifact in a release pipeline with a CI trigger on the primary artifact (either A or B) then when the release triggers it could be using mismatched versions of artifacts as 10 NuGet packages from 10 different commits are complete before I even get 2 VM images made by the other CI pipeline. I thought maybe build/artifact tags could solve this so that my release waits for artifacts which all have the same tag but I can't use variables in build/artifact tag filters which makes this not really amendable to any sort of automated scheduled/trigger.
Is this some good pattern for this type of workflow?
For this issue , based on your workflow, I am afraid that it is impossible to achieve a fully automated release. Enabling the Continuous deployment trigger will create a new release every time when a new build is available. Since the two artifacts are not generated at the same time, the two matching artifacts cannot be used as the source in automatic release.
To use specific artifacts as source in a release, we usually specify the version in Artifact. But this can't achieve continuous deployment. One way is to merge jobs A and B to generate an artifact, so that you don’t need to worry about the corresponding issues of artifacts, but according to your actual situation, I ’m not sure about the feasibility of this.
do a 'wait all' type operation on N input artifacts so that my release
pipeline only starts when each artifact has a version available that
matches some specified value
Apart from the negative answer, I think what you want is a good idea! So I post a feature request here in DC forum. You could vote that suggestion ticket and share your comment there.The product team would provide the updates if they view it. Thank you for helping us build a better Azure DevOps.
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.
I have branch validation in the form of a PR Build, which means I have duplicated my original build and removed some steps (such as pushing to my docker registry).
I would prefer to simply be able to automatically add a tag / some kind of identifier to a PR build and exclude the step on the original build using custom conditions.
Does anyone know if this is possible, and if so how to achieve it? I'd really rather not duplicate each and every build.
If I understand your question correctly, you would like to run a build step based on a custom condition. In this case, the custom condition is whether the build is a PR build or not.
You can check the pre-defined build variables available in Azure Devops here and you can see that there is a Build.Reason variable.
I am listing a few variables here.
Manual: A user manually queued the build.
IndividualCI: Continuous integration (CI) triggered by a Git push or a TFVC check-in.
PullRequest: The build was triggered by a Git branch policy that requires a build.
You can specify the condition in custom condition settings of your build step like this.
More examples available in the docs