In TeamCity 2020.1, we have introduced a highly demanded feature – conditional build steps. With new execution conditions, you can control whether or not a given build step is executed in every build run, depending on the current environment and parameters. In this video demonstration we: explain how to add an execution condition to a step; show how to elevate your building experience by creating custom conditions based on build parameters. Here is a quick recap of the video: Adding execution conditions To add execution conditions to a build step: Open the step's advan

Developing a working piece of software is difficult. Just like building an airplane, it requires talented people, working components, and a testing framework. No plane leaves the hangar before everything is ready, checked and double-checked. In JetBrains, we adopt the same philosophy for building our software. Vigorous testing helps us discover bugs and problems before the final product takes off. Just like building a plane, software development is a process that consists of multiple stages. Although the authors of this post are not aerospace engineers, we will use simplified aircraft analo

In the previous blog post, we learned about snapshot dependencies and how they can be applied to create build chains in TeamCity. In this blog post, we describe how snapshot dependencies enable parallel builds. More snapshot dependencies Previously, we started creating the build chain for the demo application. We created two build configurations: one builds the application and the other builds the Docker image. What about tests? Suppose there are a lot of tests and running those tests sequentially takes a lot of time. It would be nice to execute the groups of tests in parallel. We can

In TeamCity, when we need to build something, we create a build configuration. A build configuration consists of the build steps and is executed in one run on the build agent. You can define as many build steps as you like in one build configuration. However, if the number of steps grows too large, it makes sense to examine what the build configuration is doing – maybe it does too many things! We can split the steps into multiple build configurations and use TeamCity snapshot dependencies to link the configurations into a build chain. The way TeamCity works with build chains enables quite a

TeamCity is mostly known as an on-premises CI server. But if you want to get a taste of TeamCity, you don’t really need to install it on your servers. Enter TestDrive! TestDrive is a limited cloud TeamCity offering. It is a way to try TeamCity for 60 days, without the need to download and install it. TestDrive is currently hosted on top of the teamcity.jetbrains.com server and lets you create one TeamCity project. This blog post is a getting started guide on how to set up a project in TestDrive. Logging in On the TeamCity download page, select the TestDrive tab and click “Test Dri

TeamCity provides support for multiple technologies and programming languages. In TeamCity 2019.1, support for Go has been included in the distribution. In this blog post, we will explain how to configure TeamCity to work with Go programs. Configuring Golang build feature To enable Go support in TeamCity, go to Build Configuration Settings | Build Features, click Add build feature, and select Golang from the list. The Golang build feature enables the real-time reporting and history of Go test results in TeamCity. Running Go tests Once the Goland build feature is enabled, T

The support for pull requests in TeamCity was first implemented for GitHub as an external plugin. Starting with TeamCity version 2018.2 the plugin is bundled in the distribution package with no need to install the external plugin. The functionality has since been extended in version 2019.1 to support GitLab and BitBucket Server. In this blog post, we will share some tips for building GitHub pull requests in TeamCity. First, there are a few things you need to know about when configuring the VCS root in regards to pull request handling. Next, we’ll cover Pull Requests and the Commit Status P

In this blog post, we are going to look at how to test TeamCity configuration scripts. Getting started with Kotlin DSL Working with configuration scripts Creating build configurations dynamically Extending Kotlin DSL Using libraries Testing configuration scripts Given that the script is implemented with Kotlin, we can simply add a dependency to a testing framework of our choice, set a few parameters and start writing tests for different aspects of our builds. In our case, we’re going to use JUnit. For this, we need to add the JUnit dependency to the pom.xml file

Missing a feature in TeamCity? Build your own plugin! To learn how, join us Tuesday, April 30th, 16:00 CEST (11:00 AM EDT) for the Getting Started with TeamCity Plugins webinar. The webinar introduces you to the ins and outs of plugin development for TeamCity. How to get started, where to find the docs and samples, what are the typical use cases, and even more importantly – where to ask the questions! We will develop a new plugin for TeamCity from scratch, explore the possible extension points, and discuss the essential concepts. In this webinar: Use the Maven archetype for TeamC

Getting started with Kotlin DSL Working with configuration scripts Creating build configurations dynamically Extending Kotlin DSL Using libraries Testing configuration scripts In the previous post, we have seen how to extend TeamCity’s Kotlin DSL by adding new abstractions. If the new abstraction is generic enough, it would make sense to reuse it in different projects. In this post, we are going to look at how to extract the common code into a library. We will then use this library as a dependency in a TeamCity project. Maven project and dependencies In the first po

Getting started with Kotlin DSL Working with configuration scripts Creating build configurations dynamically Extending Kotlin DSL Using libraries Testing configuration scripts TeamCity allows us to create build configurations that are dependent on one another, with the dependency being either snapshots or artifacts. The configuration for defining dependencies is done at the build configuration level. For instance, assuming that we have a build type Publish, that has a snapshot and artifact dependencies on Package, we would define this in the build type Publish in the foll

This is part three of the six-part series on working with Kotlin to create build configurations for TeamCity. Getting started with Kotlin DSL Working with configuration scripts Creating build configurations dynamically Extending Kotlin DSL Using libraries Testing configuration scripts We have seen in the previous post how we can leverage some of Kotlin’s language features to reuse code. In this part, we’re going to take advantage of the fact that we are dealing with a full programming language and not just a limited DSL, to create a dynamic build configuration.