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
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 want to have my build pipeline configured such a way that when ever my pipeline fails there is a bug created for the same. I cannot find an option to select this configuration for a particular branch. Can someone help me with this.
I want to create a bug whenever my build pipeline fails in azure devops. And i want to have it configured for a particular branch
There is an option Create a work item on failure on the pipeline Options tab.
If the build pipeline fails, it can automatically create a work item to track getting the problem fixed.
But we could not configurate it for a particular branch for this option, but we could create a new pipeline with trigger filter Branch specification:
In this case, only the particular branch build failed, it will create a bug.
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.
Is there a way I can set up a build in Azure DevOps to automatically run every time a PR is merged and completed and contains a specific keyword in the name? for example: "Some PR name here [RUN_BUILD_123]"
Edit:
The reason for this is because I have different builds on top of the same branch so instead of triggering all the builds I just want to trigger those that I know need to be rebuilt based on the particular projects getting changed.
A PR has a target-branch. If you want to trigger a build after a PR is completed just configure a build with a ci-trigger for that target-branch. You can't check for certain keywords in the PR-name unfortunately
Agree with D.J. For detailed setting, you can check the Enable continous intergration option in the Triggers settings, then select the target branch you want ci-trigger build in the Branch filters.This will automatically trigger the build after pr is completed.
But you can't do it if you want to include special keywords in pr name.
Topic is a bit old, but if there is anyone who want's to archive this stumbling over this topic - here is my approach how I would solve this:
The basic of all are scripted pipelines, so if you still do it in the GUI - that's wasted time. Create a .yml build and put it into your Git. The M$ documentation is really helpful with this.
Create the trigger for your branch
Put this on the first line, so the pipeline will be executed when master (or your branch) has a new commit
trigger:
branches:
include:
- master
Read out the commit message via the VSTS variables
Trigger the builds, based on their ID via REST API (you can use the pipeline token for authentication)