Child pages
  • Kanpur 2019.1 EAP3 (build 65740) Release Notes
Skip to end of metadata
Go to start of metadata

See also:

Kanpur 2019.1 EAP1 (build 65427) Release Notes
Kanpur 2019.1 EAP2 (build 65579) Release Notes

On this page:

Improvements for Amazon spot instances

In this EAP, we have improved the TeamCity support for Amazon EC2 spot instances.

  • In accordance with how EC2 services manage instances, we have made the 'Max price' value optional for spot instances so they can be launched exactly like the on-demand ones.
  • You can now configure spot fleets (collections of instances) to run images, which allows cutting costs by always utilizing just enough instances.
  • Since this version, we use mandatory tags for all Amazon instances run by TeamCity, which helps identify TeamCity instances after rebooting a TeamCity server. The ec2:CreateTags permission on Amazon is now required.

Before enabling spot instances, make sure that your Amazon user profile has the following permissions:

  • ec2:CreateTags

  • ec2:RequestSpotInstances

  • ec2:CancelSpotInstanceRequests

To configure an allocation strategy for a spot fleet, open the AWS Management Console and go to EC2 | Spot Requests | Request Spot Instances. Here you can select the strategy, set the target capacity, add tags, and so on. Refer to Spot Fleet Requests for more information on the available parameters. When you are done, download the configuration as a JSON file.

Now you can add this configuration to the settings of an Amazon image in TeamCity. Select ‘Spot fleet options’ in the ‘Spot instances’ drop-down list and insert the JSON configuration into the text area below.

 In this EAP build, some parameters from the JSON configuration are still available in the TeamCity UI. If you set them both in the UI and in JSON, TeamCity will use those set in the UI. An exception is the instance tags: tags, added in the UI, will be added to the list of tags declared in the JSON configuration.

We’re planning to redesign the current implementation, so be aware that you may have to change the image settings in the next versions of TeamCity.

You can monitor the state of all running instances on the Agents | Cloud tab.

Build artifacts publishing options

Build artifacts may comprise distribution packages, log files, reports, and so on, taking up a lot of storage space. When a build fails often, you may want to restrict artifacts publishing to successful builds only in order to save disk space.

In other cases, you may need to investigate artifacts even if a build has been interrupted.

To support all these scenarios, we have added two new options for publishing artifacts to the General Settings of a build configuration.

Now you can choose when to publish artifacts:

  •  ‘Even if build fails’ (default): as in the previous versions of TeamCity, artifacts are published at the last step of a build if all previous steps have been completed, successfully or not. If the ‘stop’ command is issued, artifacts are not published.
  • Only if build status is successful’ (new): artifacts are published at the last step of a build if all previous steps have been completed successfully. TeamCity checks the current build status on the server before publishing artifacts.

  • ‘Always, even if build stop command was issued’ (new): artifacts are published for all builds, even for interrupted ones (for example, after the ‘stop’ command was issued or after the time-out, specified in the build failure conditions).

Note that if the ‘stop’ command is issued during the artifacts publishing, the publishing operation will be stopped regardless of the selected ‘Publish artifacts’ option.

Docker requirement for build agents

In 2019.1 EAP3, a requirement for build agents is implemented in the Docker Support plugin. If the ‘Docker Support’ feature is added to a build configuration, a TeamCity server will automatically analyze all agents and add those with installed Docker to the list of ‘Compatible agents’.

Parsing of Go tests

Since this version, TeamCity can parse Go tests.

To build Go projects, make sure a Go compiler is installed on an agent and add the 'Golang' build feature to a build configuration.

To enable parsing of Go tests, run them with the  "-json" flag:

  • either add this flag to the Command Line build runner's script: "go test -json".
  • or add the "env.GOFLAGS = -json" parameter to the build configuration.


Make sure you use only one of the methods to set the ‘-json’ flag. Setting it in both build parameters and the runner’s script will make Go fail to build.

Token-based authentication

In addition to basic HTTP authentication, TeamCity now supports authentication based on permanent access tokens. With tokens, you don’t need to expose a user login and password in scripts. Tokens are also convenient for the REST API authentication.

To enable token-based authentication, go to Administration | Authentication and add the corresponding HTTP authentication module.

 If you delete this module, all previously generated tokens will be preserved in the database but they could no longer be used for authentication until this module is added again.

 In My Settings & Tools | Access Tokens, each TeamCity user can generate a unique token (up to 36 tokens per user) and pass it in an authentication header to access the TeamCity API:


The TeamCity administrator can generate tokens for all existing TeamCity users in Administration | Users | <User> | Access Tokens.

 If you no longer need a certain token and want to prevent its usage, simply delete it from the ‘Access Tokens’ list.

New TeamCity documentation website

We have reworked the documentation for 2019.1 version of TeamCity.

To create a better user experience and ensure a common look and feel across the documentation of all company products, we have migrated our documentation from Confluence to a new platform. We switched to the Docs as Code approach which allows us to write and publish documents similarly to how we write and build the source code of the TeamCity itself.

The main product documentation is accessible on the new documentation website, while the Plugin Development Help is now residing on a separate location. We have decided to move the source files of the SDK documentation to the public GitHub repository so our community can contribute to it. You can access the Plugin Development Help from the page tree of the main documentation.

The new documentation platform is a work in progress. We will be grateful for your feedback and any ideas for improvement.

You can still find the documentation for previous versions of TeamCity in Confluence.

Other improvements

  • No labels