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.
Related
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
I have a TFVC project with about 4 branches. I need to somehow setup build and release pipelines that build an artifact for each branch. Because I will eventually need to repeat this process elsewhere, I would like to prevent having to duplicate the same build pipelines for each branch. I am able to configure a single build pipeline that works on whatever branch I need using a user-defined variable when the pipeline is kicked off, but now I need to enable continuous integration on the build.
My current build pipeline trigger configuration
I need this to work such that whenever someone checks into one of the TFVC branches, the build is kicked off and can correctly identify which branch was updated. From what I have found, this means that my initial idea of a user-defined variable is not going to work any longer. Is there a predefined pipeline variable that I can use to tell which branch was checked into, so that that branch is the one that is checked out and built? If not, is there some other way to do this in one pipeline, or do I ultimately need to duplicate this build pipeline for each branch?
Sorry, it's not available with TFVC in Azure DevOps/TFS build pipeline.
For CI trigger, you could select the version control paths you want to include and exclude. In most cases, you should make sure that these filters are consistent with your TFVC mappings on the Repository tab. It's not able to dynamically set workspace mapping path based on the branch which continuous integration trigger your build pipeline.
You could also take a look at Daniel's explanation in this question: When my TFS build is triggered by a branch-specific check-in, why doesn't it set that branch as its source?
TFVC relies on workspace mappings to know what to download. The workspace mappings can encompass multiple TFVC repos across different
team projects, multiple branches within a single repository......
As a result, there's no way for it to understand how to dynamically change workspace mappings to be for a specific branch.
Conclusion: You may need one build for every branch, duplicate the pipeline simply change the path filters in trigger and workspace mappings.
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.
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