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:CreateTagspermission on Amazon is now required.
Before enabling spot instances, make sure that your Amazon user profile has the following permissions:
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).
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 "
- 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.
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.
New API for setting agent requirements based on build features.