Bazel plugin for TeamCity

Bazel is an interesting build tool for compiling large projects and it comes with build-ins for Java, C++, Python, etc. Some of our users are adopting Bazel and we received a few requests to support it in TeamCity.

Bazel plugin for TeamCity is now published in the plugin repository and could be installed as an additional TeamCity plugin. The plugin provides Bazel command build runner and integrates with the core functionality of TeamCity.

bazel-build-stepBazel build step configuration

You will be able to see Bazel’s command output in the structured build log. The plugin also assists in capturing the test execution to provide test report and history of executions.

bazel-build-logStructured build log

Also, some convenience features were added to make it easier to configure Bazel builds:

In addition to the build runner, the new plugin provides a build feature to configure the common startup options and the remote cache for Bazel builds.

bazel-build-featureBazel build feature configuration

Here’s a simple experiment with java-maven example. Running the “build” target for the project required approximately 17 seconds without the remote cache. Adding the remote cache to the build configuration resulted in 7 seconds build time.


You can now download and install the Bazel plugin for TeamCity and give it a try and let us know how it works for you. Any feature requests — feel free to submit to YouTrack!

Posted in Features | Tagged , | Leave a comment

TeamCity 2018.2 EAP2 is available

We continue working on the new TeamCity version and this EAP build provides the following new features:

  • You can now install plugins directly from the JetBrains repository: no need to download the plugin first and then upload it to your TeamCity instance manually, no need to restart the server.
  • Updating plugin can now be done via the UI: you still need to restart the server.
  • Good news for plugin developers: when installing your plugin or its updates, you do not need to restart your development server.
  • If you are a project administrator and want to restrict your users from changing the project template settings in their build configurations, you can now enforce build steps and build requirements in your project template.
  • This build comes with a new build feature, GitHub Pull Requests, enabling you to choose which pull requests will be built by TeamCity. You can filter PRs by target branch and author.


All in all this EAP build fixes about 50 issues; see our release notes for details.

Download Jaipur 2018.2 EAP2 and install it on a trial server: this is not a production-ready version of TeamCity, it changes the TeamCity data format and the downgrade is not supported.
If you installed the previous TeamCity EAP build, you can easily upgrade with our automatic update.

As with any EAP version, this one comes with a 60-day Enterprise evaluation license for an unlimited number of agents and build configurations.
You’re welcome to try this build and share your feedback in our forum or tracker.

Happy building!

Posted in EAP, Features | Tagged | Leave a comment

TeamCity 2018.2 EAP is open

Today we’re releasing the first build of the early access program (EAP) for TeamCity 2018.2.

This version will be interesting for users who are already working or just want to start with TeamCity projects and build configurations using DSL based on the Kotlin language. We now provide a convenient option of viewing the DSL for a build configuration setting right in the UI, which means that when you change the setting, you can see how its Kotlin DSL changes. You can also see the DSL code for the whole build configuration.


We always carefully listen to your feedback and quite a few requests were related to using TeamCity as a NuGet server. Besides support for NuGet Server API v3, this build introduces the ability to specify several NuGet feeds for a project:


The improvements in the TeamCity Rest API now let you work with multiple builds and cancel, delete, pin/unpin, and tag/untag them.

We also continue improving the TeamCity Web UI.

All in all this EAP build addresses about 80 issues; see our release notes for details.

Download Jaipur 2018.2 EAP1 build, and make sure to install it on a trial server: the new version changes the TeamCity data format and the downgrade is not possible.

Our EAP versions come with a 60-day Enterprise evaluation license for an unlimited number of agents and build configurations: you’re welcome to try this build and share your feedback in our  forum or tracker.


Posted in EAP, Features | Tagged | 2 Comments

TeamCity 2018.1.3 is released

We have just released TeamCity 2018.1.3, the update containing about 80 fixed issues.
Our UI keeps improving and this version comes with a prettier, faster branch selector:











Among other improvements, we should mention fixes for memory leaks on the server side and on the read-only server, a number of problems in Kotlin DSL as well as some other performance and stability fixes.

We recommend upgrading as this release also addresses a few security problems: the complete list of fixes is available in our release notes.

As usual with our bugfix updates, TeamCity 2018.1.3 has the same data format as all 2018.1.x versions, which provides for easy upgrade/downgrade within these builds.

Remember to check our Upgrade Notes and use one of the upgrade options:

  • easily upgrade from a recent version with our automatic upgrade
  • download the new version from the website or
  • pull the new version of the TeamCity docker image

Your feedback is welcome in our forum or tracker.

Happy building!

Posted in Bugfix, Release | Tagged | Leave a comment

GitHub Pull Requests plugin for TeamCity

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 it is impossible to distinguish pull requests by their target branches. Moreover, it is a known fact that even if a pull request is closed in GitHub, the corresponding branch remains in a Git repository. It is not so uncommon to see repositories with several thousands of pull request-related branches. In TeamCity they clutter the user interface and make the performance worse.

TeamCity does not know who opened the pull request either, so it is not possible to limit the builds of pull requests opened by the organization members only. As a result, if third parties can open pull requests for your repositories, configuring TeamCity to build pull requests imposes a big security risk.

GitHub Pull Requests plugin

The new GitHub Pull Requests plugin is intended to address all the issues described above. As stated in the plugin name, it supports GitHub and GitHub Enterprise only.

The plugin provides a build feature which allows filtering pull requests that you want to build:

The author filter in the build feature configuration settings provides the following options:

  • PRs coming from the members of the same organization only
  • PRs from the members and all external collaborators
  • PRs from everybody.

Once the new build feature is added to a build configuration, TeamCity will provide additional details for the pull request branch on the build overview page:

The plugin is compatible with TeamCity 2018.1.x. You can download it from the plugin repository.

As usual, we will be happy to get your feedback! Our forum and tracker are at your disposal and if you encounter any problems, please share them with us to help us improve.

Posted in Blogroll, Features, FYI | Tagged , , , | 11 Comments

TeamCity on Azure Marketplace

Some time ago we announced TeamCity Azure Resource Manager for TeamCity deployment in Azure cloud. Now we’re glad to provide the TeamCity offer in the Azure Marketplace for streamlined TeamCity setup.

It is also available as a TeamCity download option on the official JetBrains site:


The offer lets you run a JetBrains TeamCity server and a local agent on an Azure Linux VM in Azure.

Today we’ll go over a TeamCity instance setup on Azure, which will save you time and effort of configuration tasks.


You’ll need an Azure subscription and about 10 minutes to set up TeamCity.
Note: Make sure you have a contributor and user access administrator roles on Azure.


Most of the TeamCity installation is automated, all you need to do is perform a few steps:

  1. Log in to the Azure portal.
  2. In your browser, open the TeamCity offer in the Azure Marketplace.
  3. Select GET IT NOW
  4. Review the pricing and terms information, select Continue.
  5. Select Create at the bottom of the page to configure a TeamCity installation.
  6. Configure settings:
    1. In the Basics tab, create a new resource group, in our case teamcity_demo:
    2. Configure Virtual machine settings: provide the username and authentication type. The recommended approach is to use SSH key for that. Password authentication is not recommended due to the known issue with CoreOS metadata service which breaks the startup of the default build agent. The Domain name label, DNS Prefix for the TeamCity server, will be auto-filled for you. If editing it, make sure it is globally unique.
      At this step, you also need to configure and save the subnet settings. Click OK to save the Virtual Machine settings.
    3. On the Additional Settings tab, select the TeamCity installation size and provide a password for the MySQL database of your TeamCity instance.
    4. Review the summary on the next screen. If required, download the template and parameters on your local machine for future use. Go on creating the TeamCity instance by clicking Ok.
  7. Review the privacy policy and if you agree, proceed by using Create. The deployment in progress message appears and you can click on it or the notification icon at the top to review the progress. The Operation Details link can be useful if an error occurs.
  8. Click Refresh. Upon a successful installation you’ll see the TeamCity URL name in the deployment Outputs tab:

That’s it! Now you can use the URL to access your TeamCity instance: you’ll need to accept the license agreement and set up the administrator account credentials.

You are ready to use your TeamCity installation, which includes the server and one local agent. See the TeamCity Quick start guide to configure and run your first build.

You might also want to expand your installation and make it more flexible by performing a couple of additional steps.

Adding Azure agents

Your TeamCity setup includes a TeamCity server and a local agent. You can add more agents to your installation using the cloud profile:

In the TeamCity Web UI, go to the Project Settings | Cloud Profiles and select Azure to create a cloud profile to start TeamCity agents:teamcity-profile

Configure a VM image:

Select teamcity-demo resource group, set container (preview) as the image type, and specify the jetbrains/teamcity-agent docker image. Configure the remaining settings and save them.

Note that specifying the storage account will persist container volumes in Azure, preventing the agent upgrade on each start.


After you finish the setup, it’ll take the agent about 10 min to connect to the TeamCity server: this time is required to start a VM from the created image, then the machine needs to download all the required plugins, etc.

The connected agent will be visible on the agent page:


Configuring artifact storage

By default, TeamCity uses built-in storage for artifacts. To switch to Azure cloud storage, perform the following:

  1. In the TeamCity Web UI, go to the Project Settings | Artifacts Storage tab. The built-in TeamCity artifacts storage is displayed by default and marked as active.
  2. Click Add new storage. Select Azure as the storage type. Optionally, provide a name for your storage.
  3. Supply your storage credentials:
    1. in the Azure portal, go to Storage accounts -> Access keys and copy the storage account name
    2. paste it to the account name in the TeamCity.
    3. Perform the same for the key – any of the two keys available on the portal will work.
  4. Save your settings.
  5. The configured Azure storage will appear on the Artifacts storage page. Make it active using the corresponding link.

Now TeamCity will store build artifacts externally.

Happy building!

Posted in FYI, News & Events, Partner | Tagged | 2 Comments

TeamCity 2018.1.2 is released

We are happy to announce TeamCity 2018.1.2, the bugfix update containing over 100 fixed issues in various areas of TeamCity. The changes are mostly related to

  • Kotlin DSL
  • Performance
  • Security (several new XSS’s were fixed)

Besides, starting from this version TeamCity supports several read-only nodes running simultaneously.

The complete list of fixes is available in our release notes.

Check the Upgrade Notes before you install the new version and do not hesitate to upgrade: version 2018.1.2 has the same data format as all 2018.1.x builds do and makes it possible to upgrade/downgrade between these versions.

TeamCity offers several upgrade options:

Your feedback is welcome in our forum or tracker.

Happy building!

Posted in Bugfix, Features, Release | 10 Comments

New in TeamCity 2018.1: Inherited build steps configuration improvements

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 2018.1, for a given template it is possible to define build steps and then define their placement in respect to build steps defined in a build configuration. The build configuration steps are represented as a placeholder in the Reorder Build Steps dialog. The template steps can be placed before or after this placeholder.


This looks like a neat solution to the problem I described above! :)

Even more: it is possible to override the inherited build steps right in the build configuration. For the rare occasions, it makes sense! For instance, what if for one of the build configurations I want to upload the binaries to some different repository than the one defined in the template? I could just add altDeploymentRepository parameter to the build step – voila!


The build step will be marked as overridden in the list of all steps of the build configuration.

Posted in Blogroll, Features, Tips&Tricks | Tagged , , | Leave a comment

New in TeamCity 2018.1: Enforced settings

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 template in the project:


To some extent, the enforced settings template works similarly to the default template – i.e., build configurations inherit all of its settings in the project hierarchy. The difference is that these inherited settings cannot be disabled or overridden anyhow.

In addition to that, only system administrator can associate a project with a specific enforced settings template, project administrator permissions are not sufficient. So it makes sense to store the enforcement template in a place that is only editable by a system administrator, for instance – in a Root Project.

On the other hand, the template itself can be edited by a project administrator who can administer the project where the template is defined. If the enforced settings template is specified in a project and another template is assigned as the enforced settings in a subproject, the subproject’s template has the higher priority.

Currently it is not possible to enforce VCS roots, build steps, triggers, dependencies and requirements. Let us know if you see valid use cases when this would be useful.

Posted in Blogroll, Features | Tagged , | Leave a comment

New in TeamCity 2018.1: Project Level NuGet feed

TeamCity integrates with NuGet package manager and can also serve a NuGet feed. Using TeamCity as a NuGet feed comes handy if you want to publish your NuGet packages to a limited audience – just to your team, for instance.

Before TeamCity version 2018.1, NuGet feed was global for the whole server. And it was only possible for the system administrator to enable the feed.

Having a global feed could lead to a substantial size, delays with packages appearance, etc. TeamCity 2018.1 addresses those issues by allowing to enable a NuGet feed at the project level, which means each project can have a dedicated feed. As a consequence, the project administrator has the authority to enable the feed, which reduces the administrative overhead.


By default, TeamCity no longer adds all .nupkg artifacts to the project feed. To index packages published by selected build configurations only, add the NuGet packages indexer build feature to these build configurations.


Alternatively, to index all .nupkg files published as build artifacts in the project, enable Automatic NuGet Packages Indexing on the NuGet Feed page of the project settings.

Posted in Blogroll, Features | Tagged , | Leave a comment