Dynamically setting VCS branch
I have multiple VCS roots set up (Core, AuthN, Other). Due to cross dependencies, when we build Other, we need to download Core and AuthN in order to build a testing database for integration tests. Where I'm having issues is that we'll have up to 3 different branches of each active at any time: Current, Patch, Hotfix. When Other builds, the correct branch of the other 2 needs to come down as well, (e.g. if Other's Hotfix branch builds, it needs to pull Core and AuthN's Hotfix branch). Since these specific build numbers change on a regular basis, I'm uncertain how to get Other to identify which branch it needs.
I have Other set up with 3 VCS roots (one for Other, Core and AuthN), each with their own branchName parameter as the default branch. I also have a series of parameters created that identify what the current patch and hotfix versions are for the next releases. I then created a PS script, that uses these values, plus the current branch name (Other's version), to set Core and AuthN branch names, but that build step doesn't run until after VCS downloads have completed. How can I get the correct version of Core and AuthN for a given version of Other
Please sign in to leave a comment.
Hi Wes,
Your scenario should work out of the box, without needing any kind of scripting or weird configuration, if you are using a VCS type which has support for branches. Add the branches you want to track to the branch specification. Then, once you select a branch for a build, it gets marked as the "logical branch" for that build, and all builds in that chain (and VCS Roots) will try to pull that branch, assuming it exists. If that branch doesn't exist, it will try to pull the default branch. (More info on the logical branch name here: https://confluence.jetbrains.com/display/TCD10/Working+with+Feature+Branches#WorkingwithFeatureBranches-Logicalbranchname)
If you have already tried this, and it's not working, please provide the following information:
-Types of VCS Roots you are using (SVN, Git, Mercurial, etc)
-What happens when you select a given branch to be built, which branch is picked out of each of the VCS Roots.
Thank you for your reply.
We're using GIT.
In order to explain which branches I saw being built, I think it would be helpful to go over how things are set up a bit more specifically. Lets say I have the following branches for the 3 repos previously mentioned
Core branch names:
AuthN branch names:
Other branch names:
I have 3 VCS roots set up -- one for each of the above repositories. Each root is defaulted to a dummy branch of "hack" (to prevent meaningful things from happening when a branch isn't explicitly provided) and watching for other branches whose names start with their major build number (e.g. Core looks for 5.*) to exclude inadvertent changes to past releases. Each VCS root is shared to whichever project needs it.
I have 3 build projects set up -- one for each repository. Core has it's own root. AuthN has it's own root plus Core. Other has it's own root plus Core and AuthN.
For example. When I build any of the branches, its dependencies should also come down, but for the appropriate release type.
When I build Other 5.5.1.0 (Hotfix), Core 5.0.1.0 and AuthN 6.1.2.0 branches should come down
When I build AuthN 6.2.0.0 (Patch), Core 5.1.0.0 should come down.
Are you saying this behavior exists by default? Based on my testing, the "hack" dependencies were continually the ones that were pulled. The only branch that actually pulled correctly was the primary one being built.
Thanks again!
Sorry for the delay, I've been out for a bit. I got the problem now. From your description I understood that the names of the branches did match. That's what we consider a logical name branch and what should work. Your scenario is definitely not supported by default, but has some solutions.
The default way for this would be to set the checkout mode to "do not checkout files automatically", that way you can customize what you get. There are several parameters set up to ease the scripting in this regard, but you would still need to do it in your script instead of letting teamcity perform the checkout.
Another possibility could be to use a template to share the steps, configuration parameters, etc, but have different build configurations (or projects) per-branch-"type", setting the default branch / branch spec via parameters. Have a build configuration for "Current", another for "Patch", and another for "Hotfix". Then you can set the branches to whatever values are appropriate per build/project and as there is only one, there won't be issues. Having most (or all) the configuration in the templates, except the parameters where the branches are defined, should have very small maintenance overhead for this projects, and changing the branch values would be as simple as updating the parameters.
There is a last option, but dependent on your structure. Per my description, if "Current", "Patch" and "Hotfix" had the same name (which is what I had initially understood), TeamCity would definitely pull this off automatically. This would also work if "Current" were "6.0.0.0" for all of them. I understand this can be problematic, but would automatize this process.