Unable to setup parameterizied VCS root/versioned settings
Hi,
this is my first post, so please let me know if this isn't the right place to ask that kind of questions.
1) My first question regards the usage of versioned settings:
Our current approach is to have a parent project A which configures a VCS root with a parameterized url:
"https://git.serverurl.de/path/morepath/%system.teamcity.projectName%.git"
The project name always equals the repository name. Several sub projects would reuse this vcs root, but only their build configurations refer to the vcs root.
This approach worked on projects without the usage of versioned settings (using templated build configurations) but for our new approach of creating sub-projects that rely on versioned settings Teamcity is unable to resolve the reference %system.teamcity.projectName% in the versioned settings tab when we choose said vcs root, leading to an error (~"unresolved url", because the reference to the system parameter was used verbatim).
Is there a way to dynamically reference repositories (e.g. project name equals repo name) that avoids having to manually specify the vcs roots url?
2) The second question is about the branching of vcs roots:
When specifying a vcs root I have to set a default branch from which the versioned teamcity config is pulled and rendered.
We have to deal with several unique/different projects which won't allow for a one-config-to-rule-them-all setup, which means we have to adjust some of the build configurations.
Our goal is to have a basic teamcity config setup to start but we want to be able to configure the teamcity config on a dev/feature branch and build that dev/feature branch which this new config.
Can we do so, without having to re-specify the vcs root's default branch?
This would make it nearly impossible for us to reuse that vcs root for multiple projects (see 1st question).
Version: TeamCity Enterprise 2019.1.2 (build 66342)
Please sign in to leave a comment.
Hi David,
this is the correct place to ask this kind of questions, but if you hold an Enterprise license you are entitled to premium support: https://confluence.jetbrains.com/display/TW/Feedback
Regarding the VCS Root, I'm not sure that %system.teamcity.projectName% should work at all. As far as I can tell testing the connection doesn't work unless you have defined yourself the parameter at the project level, which should mean it doesn't work in many scenarios. It will work within builds if the parameter is resolved under some scenarios (such as a build starting), but it's not defined otherwise and thus you see the problems you experience at the versioned settings page. I'd recommend either forcing the parameter to have the value by adding it in the parameters tab or using a different one that you define on your own. That would also help should the repository be moved or should the project need to be renamed. In particular, redefining
While we do recommend using parameters for root URLs, we recommend setting them on your own rather than depend on this ones.
Regarding your second question, we do recommend to stay away from the "one-config-to-rule-them-all" set up entirely, but I think we would need to dive into more specifics. If different branches require different settings, we would normally recommend to have different build configurations for the different branches, as this would allow a much easier way of identifying what is happening when and where. Having build configurations be modified regularly leads to issues understanding what happens easily which are counterproductive to the goal.
If you can share specifics or an example here we could try to dig into it and make some suggestions. If you would like them to stay private, you can use the private methods mentioned in the link above.
You can also use a parameter for the default branch, and define that parameter at the project/build configuration level. That way, you can reuse the VCS Root but still alter the default branch for the different projects. It's also perfectly possible to simply add the branches to the branch specification if a single build will use more than one branch, but we do not recommend adding all branches to a VCS Root just to share it among different projects, as this generates other problems (such as display of pending changes, requires filtering on triggers, etc).
Hope this helps.
Hi Denis,
thanks for your reply!
Regarding my first question:
I already anticipated that I won't be able to use the parameter because as you said "the parameter is resolved under some scenarios (such as a build starting)" which isn't the case when trying to initialize a newly created projects connection to its vcs root.
We currently create new projects via the API but than have to manually setup the vcs root to point at the project's repository because of the above.
Any other suggestion on how to accomplish that automatically?
I think I have to formulate my second question better:
I want to be able to adjust the teamcity config (as code) on a development branch (which is needed in some cases). But I don't want to have to switch the VCS rots default branch to that development branch. If I don't do so, then TC does of course not pick up the adjusted TC config of that development branch.
Can I force TC to build a certain branch according to that branches TC config without having to alter the VCS roots default branch?
(Thanks in advance! I will be on holiday for the next week, but am looking forward to hearing back!)
Hi David,
If you create the projects automatically via the API, then it should be easier. Instead of using a reference to %system.teamcity.projectName%, simply create a parameter named %projectName% (or anything else) with the value of the project name, as already mentioned, then simply use that. The problem of using system.teamcity.projectName is that teamcity doesn't generate it until a specific point in the build, but parameters that you pre-generate are already there for usage, so they are perfectly fine. The REST API supports creating the projects with parameters, so you would just need to add it
About creating branch-specific settings, yes, it is doable but with some restrictions: https://blog.jetbrains.com/teamcity/2018/01/branch-specific-settings-in-teamcity/