Webinar recording: What’s New in TeamCity 10.0

The recording of our July 28 webinar, What’s New in TeamCity 10.0, is now available on the JetBrains YouTube channel.

In this webinar Wes Higbee goes over new and exciting features of the latest TeamCity release, TeamCity 10.0. He demonstrates creating projects and build configurations using TeamCity DSL; setting up a second node for handling running builds data; advancements in integrations with VCS; flaky test detection, and other new features of TeamCity.

Below is the precise timeline of the webinar and select Q&A:

1:38 Setup OAuth Connections to GitHub and BitBucket.
3:18 New options to create build configurations and projects directly from GitHub and Bitbucket.
4:08 Walk through – adding a sub project for a GitHub repository.
8:28 Seamless GH/BB issue tracking integration.
10:14 Quickly create connection for GH issue tracking.
11:41 Project popup for search and navigation.
14:39 Flaky test detection.
18:04 Commit status integration – GitHub, Bitbucket, Gerrit, GitLab, Upsource.
22:22 Adding a build feature for commit status.
25:47 Links to GH issue tracker in TeamCity change log.
28:36 Commit status showing in GitHub pull request while build is executing.
30:55 VCS settings with Kotlin instead of XML.
49:54 Prefer to checkout files on agent, then continue Kotlin VCS settings demo, talking about Pipelines defined in VCS.
55:35 Running TeamCity in a docker container.
56:35 Cross-Server Projects Popup.
59:34 Two TeamCity Server Node Configuration.
1:01:13 Cross-Server Projects Popup continued.
1:03:54 TFS cross platform support.

Q&A:

Kotlin DSL

Q: Does Kotlin work automatically for a newly created branch?
A: As with XML, TeamCity generates configuration from Kotlin files from the default branch specified in VCS root.

Q: Can you version whole project + build config hierarchies in Kotlin and deploy it all at once? Or do you have to setup each build config with its VCS root for Kotlin settings?
A: Yes, you can. Actually entire hierarchy can be generated by a single Kotlin sctript.

Q: What about meta runners in Kotlin?
A: No special syntax for them, but you can upload them as usual, and then reference them in Kotlin scripts.

Q: No autocompletion for the parameters is available, right?
A: No, but we can think about it actually. Also with Kotlin it is relatively easy to create your own statically typed version of a meta runner.

Q: Is there a cmd-line or other tool that can convert all XML projects into Kotlin? (REST API, cmd line, etc. is fine)?
A: There is no separate tool but if you put existing project into VCS in Kotlin format, it will be checking the generated Kotlin code, so that can be used to convert the settings.

Q: Kotlin code created for one project can be reused for other streams in Perforce?
A: Not sure I understood properly, but in TC10 Perforce streams can work as feature branches. Kotlin settings can be stored in Perforce stream as well, but only in a default specified stream.

Q: Is there a way to use Kotlin code to build the code locally before we submit for TeamCity to pick up?
A: Yes, there is a Maven project, so you can build/compile Kotlin files locally.

Q: Kotlin project can be duplicated and just change the project name does that work? I see few hardcoded uuid values, will leaving them as is work?
A: Uuid must be unique across the server, you can come up with your own scheme for uuids to achieve it. You can read more on it here: https://confluence.jetbrains.com/display/TCD10/Kotlin+DSL.

Q: Is it possible to configure agents settings and master server itself with via Kotlin?
A: No, only the project-related settings. You are welcome to detail what agent settings you want to store in VCS by filing a feature request into our tracker.

Q: For VCS roots, how are security credentials stored in Kotlin for ssh-keys and user/passwords?
A: SSH keys are never stored in VCS, but you can reference them by name from Kotlin. passwords are stored as with XML in scrambled form. So if you have to use password authentication it is recommended to place VCS root to parent project which is not under version control.

Q: Let’s say that we don’t like using Kotlin anymore and want to switch back. Can we switch between Kotlin and the web UI easily?
A: Yes, you can just disable versioned settings in the project, and UI will be unlocked. Nothing will be lost.

Q: Will there be any issues with Kotlin if multiple users are editing the same build configuration in different offices at the same time?
A: When Kotlin settings from VCS are enabled, editing from TeamCity administration UI will be disaled, so the only way to make changes would be to commit those to VCS. And VCS are good at solving conflicts.

Q: Can you branch TC10SpringPetClinic and automatically create project in TeamCity?
A: Creating new branches with TeamCity settings will not create new build configurations. However, builds in branches (using TeamCity feature branches support) will use the settings from VCS from the appropriate branch.

Q: Can we monitor a repo for new DSLs, will it generate new jobs?
A: Once you configure a project to store settings in the repository and then update the definitions in the repository to add a project with due parent, the project should be created in TeamCity

Improvements in VCS integration

Q: Does this version support Github webhooks? So Github can tell TeamCity when a change to repo is made, rather than polling all the time.
A: TeamCity now has better support for commit hooks (see https://confluence.jetbrains.com/display/TCD10/What%27s+New+in+TeamCity+10.0#What’sNewinTeamCity10.0-ImprovedSupportforCommitHooks) and we also work on a separate plugin which will simplify installing of webhooks into GitHub. we hope to announce it in a month or so.

Q: Would it be a good idea to use a “service account” to log into GitHub so that if an employee leaves the company and loses access to the org the build doesn’t break?
A: If you have such a service account – yes, probably it is better to use it.

Q: We have a lot of VCS roots setup, and the polling from TeamCity really puts massive load on our GitHub box.
A: Polling can be reduced now, if you start using commit hooks. But if agent side checkout will be a problem for newly created build configurations, feel free to submit a request to make default configurable.

Q: Is it correct that the default checkout mode is “on agent”? How does it affect existing build configurations? What was the reason for this decision?
A: Default checkout mode now is “auto”. It means agent will try to checkout source code if it is possible, if not, it will revert to server side checkout. The reason for this is to reduce load on the server, also in many cases agent side checkout is more efficient, so it seems reasonable to have it by default if possible.

Q: Does the agent checkout support multiple checkout rules now? That’s basically why we’re using server checkout mode.
A: There were no significant changes in checkout rules support for agent checkout. Would be great to know details as to what you want to setup, ideally in our issue tracker: https://youtrack.jetbrains.com/issues/TW.

Q: Do the pull request status show in Bitbucket pull requests?
A: Both Bitbucket server and Bitbucket cloud are supported. Full list can be seen here: https://confluence.jetbrains.com/display/TCD10/Commit+Status+Publisher.

Q: Is there any plan to add a button to get to check for any application changes instead of modifying the VCS checking interval?
A: You can set large VCS checking for changes interval and manually invoke “checking for changes” – that was available for a long time. What is new in TeamCity 10 is dedicated interval adjusting when VCS commit hooks are installed, check https://goo.gl/7Yo4t6.

Q: Is Bitbucket Server support planned?
A: Yes, but you already can use TeamCity and Bitbucket server together, it’s just that with Github or Bitbucket cloud setup of projects became simpler.

Q: Do the pull request status show in Bitbucket pull requests?
A: Both Bitbucket server and Bitbucket cloud are supported. Full list can be seen here: https://confluence.jetbrains.com/display/TCD10/Commit+Status+Publisher.

Two-node configuration

Q: My question is how the load on the systems will be spread out, so we can plan the VM sizes of a two-node system? We have over 10,000 build configurations, mostly “archived”, but many still tied into existing VCS roots.
A: At the moment if you enable second node, all of the running builds will start sending their data to this node. Internally it is also possible to do that on per-project level, so there is some internal property to control it. But in general you should not be concerned too much about VM size. It’s definitely should not be bigger than the one which handles UI.

Q: Yes, clearly it doesn’t need to be bigger. :) I can appreciate that we won’t really know until we actually try it out. Current VM is 8 CPU, 16GB RAM, so from a pricing perspective, knowing if I will absolutely need one more the same size, or two half-size, we can cost this out. Our TC server will be moving to a hosted (Azure/AWS/etc).
A: Actually it depends on how many agents you plan to have. As a wild guess, I’d say half size of your current VM should work fine. 1-2Gb of memory is ok too.

Flaky tests

Q: Is there a REST API that returns flaky tests per project/build configuration?
Q: Сan we get the test ‘Success rate’ / ‘Flip rate’ from the REST API in version 10?
A: Not yet. Would appreciate an issue in our tracker on that with comments as to how you plan to use that. Everybody interested is welcome to add their cases to https://youtrack.jetbrains.com/issue/TW-46456.

Q: Can I configure a build configuration that would re-run flaky tests?
A: For now flaky tests cannot be retrieved from TeamCity in a programmatic way, but I think we’ll add this ability at some point.

Other

Q: What about Docker integration? Still no easy way to pack application code into container, push to Docker Hub, etc.?
A: In 10 we only added official server and agent images to Docker Hub (https://hub.docker.com/r/jetbrains/). As to runners for creating Docker containers, etc. – we are working on that. Please detail what you need in https://youtrack.jetbrains.com/issue/TW-38023.

Q: Is it possible to install third-party NuGet Package directly from the WEB UI?
A: There is NuGet installer build step, you can use it to install additional NuGet packages during the build.

This entry was posted in Features, Partner, Webinar. Bookmark the permalink.