JDKs, credentials, and parameters have no possibility of centralized configuration?
So far as I can see right now, VCS roots can (sort of) have a centralized definition at a project ancestor, and meta-runners can also be shared.
But I'm missing something, there are quite a few other entities that there is no possibility of sharing, requiring a lot of copying and maintenance:
1. Java JDKs.
Different parts of our system have to be built with 3 different JDK versions. We keep our own installs of the Oracle jdks, not using anything in /usr.
But it seems that I have to manually enter each different full path of each JDK (that isn't the JDK8 that TC itself is running on) in each build configuration. And even that doesn't work too well because the path is different on linux and Windows agents. This is one thing that Jenkins seems to do much better.
2. Credentials.
Sure, VCS roots URLs can be shared, but it seems every new root has to have its credentials entered again, even though all of our many repos are all coming from a single git server and share a single git user account. There also seems to be no facility for me to maintain in a single place certain special credentials (such as sftp accounts or database accounts) which can be used in parameters, powershell scripts, or local scripts.
3. Parameters.
It seems parameters have to be defined again every time, for every parameterized job definition. There doesn't seem to be a way to define common parameters in a central place, awaiting re-use. For example, many jobs have an "incremental" checkbox. Many also have a branch select (a topic for another post). Some have a select for target host. Right now these have to be pasted in to each build config. There seems to be no way to keep them in a central place, and/or get the values/labels from an external file, and/or get the values by calling some Kotlin extension function we supply.
Please sign in to leave a comment.
Hi,
One of the core advantages of hierarchical projects in TeamCity is that build configurations and subprojects inherit all the configuration from the parent project, and all of them inherit those on the root project. If you are interested in sharing configuration such as VCS Roots, credentials, or anything, you can simply keep them in projects and they will be inherited. If you need to override some values in subprojects, simply parametrize the value and override the parameter in the given project. You can create multiple instances of the VCS Roots but this will in the long run use more resources than keeping a single one with parametrized values.
Regarding your Java JDKs, every agent reports their java versions, by default as a JDK_1x env. variable. This should be rather universal and you can reference whichever you need from within your scripts, or other variables.
If parameters are created at the project level, all build configurations in that project will have the parameters available for use with value, without needing to overwrite them. This is true for what we call build parameters: https://confluence.jetbrains.com/display/TCD18/Configuring+Build+Parameters
This won't be valid for dropdowns and checkboxes, but those can often be worked around by using metarunners that provide defaults you are interested in.
I think I covered all of your points. If you think I missed something, please don't hesitate to ask.