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.
Related
I have a build pipeline that I want to trigger when the workspace_publish branch has changes to it, which is fine and this is currently working using these settings:
However, I want the Agent to extract the SQL Scripts (on the second step) from a different branch in the "Synapse Reporting" repository, NOT the workspace_publish branch.
Is this possible?
Actually this is fairly simple. You simply add another artifact to your pipeline that points to the source control branch you are interested in:
You then have 2 artifacts that are copied over and can be accessed during your release process.
I have multiple projects in my git repo on Azure DevOps. I have build pipelines setup to trigger when commit occurs on the "staging" branch (which is our Develop branch). But I added an additional trigger that I thought would filter on a sub-folder of the repo. Currently there are three pipelines all set to trigger on commit and sub-folder. And all three run even when there is a commit with files from only one of the target sub-folders.
See the screen shot of one of my triggers:
Seems like the triggers are setup like an OR not an AND. So, in other words any commit to staging will trigger all three builds, but there are times when I don't want all three to build and publish. Just the one that I fixed should be built and published.
Is there any way to fix this?
You're right in that both Branch and Path apply. See here: https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#multiple-pipelines-triggered-on-the-same-repository
Consider migrating to yaml based builds, and set up each build in a different yaml file with it's own path triggers. Not only will this solve your issue, but you'll have the benefits of checked-in pipelines.
We have a project written in C that depends on several libraries as git submodules. We built an Azure Pipeline to build it, using multiple containers targeting multiple environments.
The challenge is that the build takes more time than we'd like, partly because of the fact that the submodules are being recompiled every time, even though they do not change.
What I'm looking for is a way to build the submodules only when needed, store them as artifacts, and have the main build consume them.
As far as I understand, I can set up a build for the submodule's repos which will poll for changes, but I want my product to depend on specific commits of the submodules - i.e. I'm not always taking the latest submodule version.
So I'm looking to trigger a submodule build whenever we switch to a new commit. Can this be achieved in Azure Pipelines? What would be the best way to manage the artifacts (e.g. store the commit ID as part of the artifact name)?
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
I am using VSTS build to run a CI build. This build definition is the same for all my git branches (master, develop, features, etc).
I am now trying to implement a deployment pipeline using VSTS release management. I plan to have two distinct release definitions. One for feature branches and one for the more important branches like develop and master. The release definition for feature branches would be more lightweight.
I think this is pretty basic and usual. In fact, that's pretty much what is documented in Microsoft's typical use case for Release Management.
For both of these pipelines, I want to configure them to start automatically using the 'Continuous Deployment' trigger. When I select this trigger, I must select an artifact source.
Unfortunately, an artifact source takes all artifacts (regardless of the branch) coming from a given build definition (my CI build). Since I use the same CI build definition for all my branches, it looks like I can't configure my two release pipelines in 'Continuous Deployment' and still use the same build definition as an artifact source.
Anybody knows how to share the same build definition for multiple release definitions but only start a release for a specific branch? Anybody knows of a way to filter by branch when we define an artifact source?
Configure branch specific release deployment
Go to release management in VSTS
Go to the definition of the release
Go to tab triggers
Add Continuous Deployment trigger
Here you can select a specific branch (for branch)
Availability of feature
This feature is available in VSTS
In the TFS on-premise version it was supposed to be available in version Server 2017.1 but it is still not available in version 2018.1
Currently there is no way in VSTS Release Management to do conditional deployment based on branch.
An alternate would be to create separate BDs for different branches and then configure them as artifact sources for the RDs.
This will also give users a clarity about the artifact from its name itself.