Webinar recording and Q&A: What’s New in TeamCity 2018.1

Yegor Naumov

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.

https://youtu.be/e37vNedsBeQ

Q&A from the session

Kotlin DSL

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 settings.kts file?
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.

Read-only node

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.

Anton Arhipov is a Developer Advocate for TeamCity at JetBrains. His professional interests include everything Java, but also other programming languages, middleware, and developer tooling. Java Champion since 2014. Anton is also a co-organizer of DevClub.eu, a local developers community in Tallinn.

Subscribe to TeamCity Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!