Blogroll

TeamCity offers a number of ways to help you work with tests. First of all, it presents the test results for each build execution so it’s easy to analyze what happened and why something has failed. Besides that, TeamCity includes advanced features like code coverage, flaky test detection, metadata in tests, and the ability to re-order the test execution. In this blog post, we provide a brief overview of these features. Test results It all starts with presenting the results. On the build configuration home page, for each build, we can see the number of tests that were executed. We can also see

⚠️ Update from October 12, 2020: TeamCity TestDrive has been deprecated. If you are looking for a simple way to try TeamCity without downloading and installing it on a server, please consider giving a try to TeamCity Cloud. TeamCity Cloud is a fully-managed CI/CD solution that automatically runs your builds and tests in the cloud, and lets your team deliver quality software faster, at scale. It is free during Beta. Continue to TeamCity Cloud 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

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.

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 Publ

While TeamCity provides a lot of functionality out of the box and bundles a number of plugins in its distribution package, there are still use cases where you might need something extra. In this blog post, we are going to list 14 cool plugins that add new features or integrate with external tools. The plugins are not bundled with TeamCity in the distribution package but can be easily installed from the JetBrains plugins repository. First, let’s take a look at the plugins that add new functionality to TeamCity for a very specific task in your build process. It could be a plugin that adds in in

Installing new plugins has just become a lot simpler! You don’t have to restart the server to enable a newly uploaded plugin anymore. The TeamCity server now integrates with the JetBrains Plugins Repository. The new integration simplifies the installation of plugins for TeamCity. By clicking the “Browse plugins repository” button in your TeamCity server, you will share some information (URL, server id, and version) with the plugin repository. With this information, the plugin repository is able to suggest installing the selected plugin version directly to your TeamCity server. The screen

The Kotlin-based DSL is becoming more popular for defining build configurations in TeamCity. We are continuing to improve the user experience for Kotlin, both in the TeamCity UI and the IDE plugin. Once the versioned settings option is enabled for the project, we recommend making new changes in the Kotlin configuration rather than in the UI. However, it might be tempting to make the changes in the UI instead of figuring out how to define something in Kotlin. For such occasions, we have added a little UI helper to assist with the DSL definitions. TeamCity 2018.2 introduces a new optio

Ever since TeamCity 2018.2, a test run in TeamCity can be associated with some supplementary information (metadata), in addition to a test’s status, execution time, and output. This information can be used to provide things like extra logs, screenshots, numeric values, and tags. You can now use service messages to report this kind of additional test data in TeamCity and then view it using the TeamCity Web UI. Consult the corresponding documentation for details. On GitHub, you can find a sample project that demonstrates the use of metadata with tests. In TeamCity, create a project from th

TeamCity 2018.1 allows you to set up a "running builds node." The node handles data coming in from the build agents. There's also the "read-only node" for handling disaster recovery scenarios. TeamCity 2018.2 expands this setup further, making it possible to delegate polling of version control systems to a secondary node. Currently, it may seem a little complicated, but our intention is simple. We want to have a scalable architecture where you can add more nodes to the cluster so that all the nodes are uniform and can perform all the tasks in an interchangeable way. The only exception wi

The hassle with Pull Requests These days pull requests is a common technique of accepting changes from third-party contributors. In fact, it proved to be so convenient that some companies started to use it even for their regular development workflows. It is possible to configure TeamCity to run builds on GitHub pull request branches. One had to provide a VCS root branch specification like refs/pull/*/head for that. However, this configuration is not without its downsides. For instance, with this configuration, the pull request for TeamCity is just a branch in a Git repository. It means that

There is sometimes a need to define a common build step in a template, so that this step will be executed either before all build configuration steps or after them. Here’s a simple example. I’m building a lot of typical Maven projects, and for most of the part their build is the same: just run mvn clean package and upload the binaries to the maven repository. However, for some of the builds, I need the additional steps to run in between mvn package and mvn deploy. In TeamCity, the requirement above can be implemented with the aid of Build Configuration Templates. Starting with version 20

Enforcing some rules in a project might be quite useful to keep the things in order. For instance, enforce agent side checkout everywhere, or make sure that all build configurations have some strict execution timeout, or enable build files cleanup (Swabra) for all the builds. Starting with 2018.1, TeamCity provides the ability to enforce settings for all of the build configurations in a project hierarchy. To enforce some settings in the project hierarchy, a template with these settings must be created. After that, a system administrator can set this template as the enforced settings temp