Is there a way to dynamically set up a VCS branch (before revisions are calculated)?
Hi,
I have a project (e.g. ProjectMain) that has two VCS roots (e.g. RepoA and RepoB). Both of them are quite big, so we use use mirrors (set up in “Checkout policy” of the VCS root settings) when checking them out. The issue with those two repositories is, that they do not have the same branch names (except 'master'). These would be some examples of correct branches pairing:
- RepoA on 'master', RepoB on ‘master’
- RepoA on ‘release/1.0.0’, RepoB on ‘release/1.x.x’
- RepoA on ‘release/1.2.0’, RepoB on ‘release/1.x.x’
- RepoA on ‘feature-3.2.0/foo’, RepoB on ‘release/3.x.x’
- etc
I am struggling with setting the correct branch for RepoB. I know that I could set it up in a way so that the user manually picks correct branches when they decide to run a build, but I would like to avoid that and replace it with some automation (afterall, calculating the correct branch is quite simple as you can see from my examples).
I have tried following:
I have created a separate project (e.g. ProjectSetup), that would calculate the correct branch for RepoB, based on the branch on which build has been run, and set it as an environment variable (e.g. RepoBBranchName). I have then set up ProjectMain, so that it depends on ProjectSetup (in a build chain way), and it would read RepoBBRanchName from it. All of that worked (I saw that RepoBBRanchName was being updated in the ProjectMain Parameters tab), but ProjectMain would already calculate VCS Root revisions BEFORE it got the correct value for RepoBBRanchName - meaning that it would default to ‘master’ and check that branch out for RepoB.
With the recent TeamCity update (2024.07 (build 160569)), a new feature was introduced (https://www.jetbrains.com/help/teamcity/2024.07/configuring-build-steps.html#Bootstrap+Steps), and I have tried that as well, but again, VCS root revision calculation happened before this new Bootstrap step, which could have potentially set the correct branch for my RepoB.
Is there a way to run some piece of code before VCS root revisions are calculated?
Please sign in to leave a comment.
From your description, I think the most viable option to address it is to set the checkout mode to "do not checkout files automatically"; that way, you can customize what you get, i.e., checkout with a script. With this option, the default build checkout directory will still be created so that you can use it to check out the sources. Please note that in this case, The build checkout directory will not be cleaned automatically unless the directory expiration period is configured: https://www.jetbrains.com/help/teamcity/2024.07/build-checkout-directory.html#Checkout+Directory+Expiration.
Best regards,
Anton
Hi Anton Vakhtel
I faced the same needs and wondering whether we cannot use parameters with wider scope then just ‘single build’ and if one build (in the same build chain) change it, then the other build can read it? In our case we could use parameter (configuration, environment, system) as 'Default branch' field in a certain CVS setting. Is it actually possible? Because in my case I would like to avoid manual checkout, because I need to reimplement checkout logic as well as authentication logic within a build step (and maybe something else I did not face yet). I even tried to do this, but the only way I can access changed parameter value (made by prev build in the same chain) is using ‘dep.’ approach. And between builds it's ok, but CVS does not have such relation to use ‘dep.’ approach.
Could you provide more details on what you want to achieve with the mentioned parameters and how you are trying to implement them? Maybe provide some examples and screenshots so I could better understand your requirements.
But generally speaking, in scenarios similar to the top message in this discussion, using the manual checkout is a recommended approach.
Best regards,
Anton
Hi,
So, the main goal is to test made changes in the database schema against previous codebase release to make sure that in case of rollback after failed deployment our code (from prev release) and schema (current) are compatible.
Here is a build chain diagram:
1. In `Dynamic branch resolver` build I define correct branch based on the chosen target branch to checkout and build codebase in `Build Code` build.
- if `target branch` = master, then `dynamic branch` = release/4.0.0 (latest)
- if `target branch` = release/4.00, then `dynamic branch` = release/3.0.0 (prev)`
- if `target branch` = feature/…, then `dynamic branch` = release/4.0.0 (latest)
2. Once `dynamic branch` is defined we need to use it in VCS_1 for `Build Code` build.
3. `Build SQL` uses the target branch to checkout and prepare sql scripts.
So, the problem for me is how to set ‘default branch’ field for VCS_1, to make auto checkout. I would avoid manual checkout, since I already faced problem how to authorize Git calls using ssh-agent and uploaded keys.
Sorry for the wait.
When the build chain is started, the revisions for each build configuration are calculated right at the start, before checkout, and before any of the build steps are executed (even the bootstrap steps are executed after the revision calculation). So, it would be impossible to control the branch with a parameter dynamically, during the build chain execution.
If you don't have a lot of combinations, you can create separate build configurations for each of the branches and set the dependencies accordingly. I think it's the easiest and straightforward solution. Using build configurations templates will allow you to make this configuration sustainable.
Best regards,
Anton
Hi Anton Vakhtel
So, I really decided to simplify my approach and used your suggestion to specify branch as build configuration parameter. I did it and using parameter overriding (reverse.dep.*.<property name>). I successfully passed a parameter to the initial build in a chain, and completed a checkout from the branch specified in the parameter.
Thanks for help!