Missed the webinar? No problem – the recording of our July 10 webinar, What’s New in TeamCity 2018.1, is now available.
In this webinar, Anton Arhipov showcases the major features of the latest release. He goes over the significantly reworked TeamCity Kotlin DSL and shows how projects can be set up programmatically, from just one settings file. The High Availability TeamCity setup with a read-only node installation is also explained. Finally, the revamped Docker support with the updated Docker runner is demonstrated, as well as the bundled Amazon S3 artifacts storage.
Q&A from the session
Q: Where can I learn more about the language used for DSL?
A: The language is Kotlin: http://kotlinlang.org/.
Q: Is there a way to define meta-runners using Kotlin DSL instead of XML?
A: Not at the moment. They are present in repository as XML files. But the point of meta-runners is to provide the ability to reuse steps. In Kotlin you can write a function which defines the steps, so probably you don’t need meta runners there at all.
Q: Do existing settings and builds defined in the Kotlin language in TeamCity 2017.2 get automatically updated to the new version or is 2018.1 backward compatible with existing declared Kotlin build pipelines and settings?
A: They will continue working as before. Since this is code, manual changes should be done to migrate DSL to the new version. First of all, the package should be changed to v2018_1, then compilation errors should be fixed. The version in
settings.kts should be changed too. Here is documentation on how to perform the migration: https://teamcity.jetbrains.com/app/dsl-documentation/jetbrains.build-server.configs.kotlin.v2018_1/index.html
Q: What would the TeamCity behavior be if we have a project configured in Kotlin with active branches and the snapshot dependencies are changed in
settings.kts for a branch which is not the default branch (for example a feature branch which adds a new build configuration to the build chain, but isn’t merged to master yet)?
A: Before triggering a build chain in a branch, TeamCity already needs to know how this chain is configured. So it can take these settings only from the current project settings. It can’t load them from the branch. So snapshot dependencies are always taken from the current project settings (basically, loaded from the default branch of the settings VCS root).
Q: Is there support for subprojects in Kotlin DSL?
A: Yes, there is.
Q: Can we specify the checkout rules for VCS builds?
A: Yes, you can specify all the same setting that you have in the TeamCity web interface.
Q: Can I use this
settings.kts file and execute the steps locally on dev environment to mimic TeamCity?
A: Unfortunately, not. The DSL generates configuration, it does not execute anything. It generates new config files, which are applied to the project and then you can run builds with new settings.
Q: How the plugin details /settings are configured in
A: All the settings can be configured by supplying a set of text properties: everything which can be configured in the TeamCity settings XML can be done via the DSL. Plugins can also provide typed API to DSL to get DSL completion for their settings configuration.
Q: Do we have a stages-like model similar to Jenkins?
A: The pipeline in TeamCity is declarative, not imperative. You define a set of configurations combined by dependencies. The server decides how to execute this pipeline, in which order, etc. Depending on the settings, requirements, available agents.
Q: Can we define different snapshot and artifact dependencies in different branches?
A: You can store different
settings.kts files in different branches and create different projects from them. But in a single project, you can’t have a different set of configurations or different dependencies.
Q: Can the build configuration differ per branch or is it always loaded from the default branch? For example, can pull requests also build with a new configuration?
A: By default, server loads settings from the branch specified in the VCS root. It is possible to configure the server to load settings from the branch where the build is executed, but there are limitations. You can’t for instance, have a different set of projects or build configurations, as well as different snapshot dependencies.
Q: Data directory can contain certificates/ssh keys – is that not a risk of adding in NAS?
A: Data directory contains all the settings necessary to access the repositories, the data should be protected with due permissions.
Q: Is there a license cost for a read-only TeamCity server?
A: No, you can run the read-only node without any extra licenses.