TeamCity Docker Images for Windows

teamcity-docker-windowsSome time ago we’ve published official TeamCity docker images for Linux. Since then Microsoft, together with Docker released support for Windows containers. And now we’re glad to announce official TeamCity Docker images for Windows containers.

TeamCity Windows Docker images are based on windowsservercore and nanoserver images and have corresponding -windowsservercore and -nanoserver suffixes in tags.

For Windows we provide the same set of Docker images as for Linux containers:

For instance, to run a nanoserver based TeamCity server, you can execute the following command:

To connect TeamCity build agent to that server you could execute the following command:

Note: due to limitations of Docker on Windows, you may not be able to access TeamCity server on localhost via http://localhost:%port% address. If this is the case, you should use non localhost IP address of your machine.

Due to some other known issues, we’d not recommend to run a production TeamCity server in Windows containers right now. But it seems fine to run a TeamCity agent inside a Windows container.

Please try these images and let us know what you think.

Happy building!

TeamCity Team

Posted in News & Events | Tagged , , | Leave a comment

Docker integration plugin now available for 2017.1.x

Greetings everyone!

As you might already know, TeamCity 2017.2 EAP builds provide new Docker integration features. They are provided by the Docker Support plugin, which is bundled with TeamCity 2017.2 EAP by default.

Today we are making this plugin available to users of TeamCity 2017.1.x as well. If you are already on 2017.1.x and use Docker, we believe the Docker Support plugin will make your life simpler, and here is why:

  • The “Docker Build” runner helps create your own Docker images.
  • The “Docker Compose” runner allows starting services using Docker Compose during your build process. The TeamCity agent will stop these services automatically when the build finishes.
  • The Command Line, Gradle, and Maven runners are also extended with the ability to execute inside a Docker container. Check this blog post for a usage example.
  • Finally, the “Docker Support” build feature provides more convenience features like:
    • automatic login to a Docker registry before the build starts;
    • the “Docker Info” build tab with information about images published to the Docker registry during the build;
    • the option for automatic deletion of the associated images from the registry when the build is deleted during the TeamCity cleanup procedure.

For details, take a look at the integration documentation.

If you wish to try this plugin, there’s nothing to stop you:

Oh, wait, there is one more option. You can actually TestDrive it in the cloud!

Happy building!
The TeamCity Team

Posted in Uncategorized | 6 Comments

TeamCity 2017.2 EAP3 is released

Greetings everybody!

We continue working on the new TeamCity version and today we are announcing TeamCity 2017.2 EAP3.

This release brings you over 90 fixed issues, as well as a number of new features which we are sure you’ll find useful:

  • TeamCity now supports automatic upgrade which can be initiated from the Administration | Update page.
  • We introduce default templates, that can be defined in a project and used to collectively modify build configurations of this project.
  • Good news for Kotlin fans – now when Kotlin settings are enabled for a project, project and build configuration settings will be available for editing from the web UI.

Please refer to the Release notes for the full list of improvements including those in composite builds, Docker support and more.

Upgrade to the new EAP version either automatically or download TeamCity 2017.2 EAP3 build as usual. Remember to install it on a trial server as it changes the TeamCity data format.

We’ll be happy to get your feedback here in the comments, on our forum or tracker.

Happy building!
The TeamCity Team

Posted in EAP, Features | 2 Comments

TeamCity Plugin for HashiCorp Vault

When performing integration tests and deployments, build scripts need credentials to access external servers and services. Traditionally passwords are stored on the TeamCity server as secure parameters. But although secrets are masked in the UI, encrypted at rest, and protected from being exposed in the build log as plain text, this often does not provide a high enough level of security.

HashiCorp Vault offers a unified approach to managing secrets and credentials, allows auditing access, and helps with password rotation.

Integration with Vault

Today we are presenting a new plugin to help build scripts interact with Vault and obtain credentials dynamically.

The plugin allows connecting TeamCity to Vault, requesting new credentials when a build starts, passing them to the build script, and revoking them immediately when the build finishes.

Usage

We expect you have installed and configured:

  • a Vault server. Refer to the Getting Started guide to learn how to launch a testing Vault instance.
  • A TeamCity server. Refer to the Getting Started guide for details.

Perform the following:

  • Download the plugin from the plugin repository, and install it to TeamCity server.
  • Configure secret backends in Vault to obtain secrets, for example AWS credentials, or generic secrets.
  • Create an AppRole in Vault for the TeamCity server to access these backends.
  • Create a connection to Vault in your TeamCity project:1
  • Next in your build configuration declare new build parameters which refer to the Vault secrets to be used in this build:

2

The parameter value has a special syntax:%vault:PATH!KEY%where PATH is the secret name, and KEY is the specific value inside.
At the moment these values can be used in the build parameter declaration only, and cannot be specified in build steps.

  • Run a build step. Deployment scripts can read credentials from environment variables, and do not need to perform any Vault-related actions:3

Besides AWS, any other Vault backends can be used. In this case:

  • Declare a configuration parameter with a value from generic backend:4
  • In a build step refer to this  parameter explicitly:5

How It Works

  • The TeamCity server stores the AppRole ID and secret, and keeps the secret encrypted at rest. When required, it can be rotated manually in the UI, or via the REST API.
  • When a new build is started, the TeamCity server requests a one-time response wrappingtoken in Vault, and sends it to a build agent.
    The AppRole secret never leaves the TeamCity server machine.
  • The build agent requests the actual secrets from Vault.
    The actual credentials are obtained from Vault by a build agent machine directly, and never transferred to the TeamCity server.
  • The build parameters are resolved and the secrets are passed to environment variables and system properties.
  • The build steps are started, and they refer to these environment variables and system properties.
  • If secret values appear in a build log, they are automatically replaced by asterisks.
  • Right after the build finish, the credentials are explicitly revoked in Vault.

Security Considerations

It is advised that you limit access to TeamCity project settings. If a person can modify build configuration settings in a TeamCity project, they can get access to the secrets. Dynamic credentials are revoked after a build, but for generic secrets this may cause more risks. To minimize the risks, split build configurations for CI and deployments into separate projects with different permissions.

Make sure build agent machines are connected to the TeamCity server via HTTPS. Only one-time tokens are transferred over network, and if they are stolen, credentials will be immediately revoked. However, it is a good practice to encrypt all traffic between the server and agents.

Feedback Wanted

This is an initial release, and we continue to improve features and user experience, and encourage you to give it a try and tell us what do you think!

The plugin is open-sourced, and published on GitHub.

If you are attending HashiConf in Austin, TX, USA next week, visit the JetBrains sponsor booth for the demonstration of this plugin and our other plugins for integrating Packer and Terraform with TeamCity and IntelliJ-based IDEs.

Posted in Features, FYI, How-To's, Tips&Tricks, Uncategorized | 2 Comments

Introducing TeamCity RunAs Plugin

When building, testing, and deploying an application with TeamCity, you may need to run a build under a specific user account, different from the one used to run the build agent.

TeamCity RunAs Plugin Overview

The teamcity-runas plugin can be used to run TeamCity build steps under a specified user account on Windows or Linux.

The plugin is compatible with TeamCity 10.0 and later.

Installing Plugin

System Administrators can download the runAs.zip from here and install it on the TeamCity server as usual.

Configuring TeamCity Agents

On Windows

The teamcity-runas plugin requires the TeamCity agent’s account to have certain permissions. Depending on the way you run the agent, granting additional privileges may be required.

  • If you are running the TeamCity agent as a Windows service under the Local System account, it has all required permissions and the teamcity-runas plugin works out-of-the-box.
  • If you are starting the agent as a Windows service using a specified Windows account (for example AgentUser), it must have administrative privileges, must have the ability to replace a process level token (SeAssignPrimaryTokenPrivilege), and act as a part of the operating system (SeTcbPrivilege) or needs to work under the Local Service account. These privileges can be added via a security policy using Control Panel | Administrative Tools | Local Security Policy | Local Policies | User Rights Assignment | Replace a process level token. See Microsoft documentation for details.
    You can also do it using the provided scripts, e.g.: runGrantAccess.cmd BuildUser.
    The changes will not take effect until the next login, so you’ll have to restart the agent.
  • If you are starting the TeamCity agent as a Windows console application, your Windows user account must have administrative privileges.

On Linux

  • With Debian/Ubuntu/Linux, the recommended setup is to run the TeamCity agent as ROOT, as in this case the account has all the required privileges and the teamcity-runas plugin works out-of-the-box (see the related section below).
  • If you run the TeamCity agent as a user different from ROOT, you need to install socat using the following command:
    sudo apt-get update && sudo apt-get install socat

Using Plugin

After the server restart, the plugin provides the Run As build feature and you can add it to your build configuration specifying the username and password.

For Windows the following username formats are acceptable:〈username〉or〈username@domain〉or〈domain\username〉.

For Windows-based build agents it is possible to specify the Windows Integrity Level, the logging level, and additional arguments.

runAS

Once the build is run, the plugin will run all the commands under the specified user account.

Checking Account Used to Run Build

You can enable the teamcity.runAs.log.enabled= true parameter of a build configuration (set to “false” by default) and TeamCity will print the required information into the build log.

runASvalidCreds

If the credentials are invalid, the build fails with “Authentication failure” error:

runASinvalidCreds

Alternatively, to make sure the teamcity-runas plugin is configured properly, you can get the user whose account was used to run the build by checking the environment variables: USERNAME (for Windows) / USER, LOGNAME (for Linux).

For example, you can add a command line build step with the set USERNAME command on Windows / echo "$USER" echo “$LOGNAME” on Linux. This will print the user whose account was used to run the build into the log.

Accessing Files created by RunAs User

It is important to note that when running a build under a specified user account, all processes run in the environment specific for this user.

It means that all files created during the build (e.g. compiled classes, object files, executables, dlls, Gradle/Maven cache files, TeamCity artifacts, some test statistics and so on) will have the teamcity-runas user as the file owner.

The TeamCity agent must have the full control over the files created in the build checkout directory and ideally, over files in other locations, e.g. m2 or .gradle directories as well. Depending on the way you configured the agent (see Configuring TeamCity Agents above), the access level will differ and granting additional permissions may be required.

For Windows, the account with administrative permissions used to run the TeamCity build agent will have sufficient rights to manage the files.

For Linux, if the TeamCity agent is not running under ROOT, it may encounter problems accessing artifacts in the build checkout directory. In this case the necessary permissions can be granted by running the following command:
chmod -R a+rwX %teamcity.build.checkoutDir%.
It can be added as the last step of the build executed under the ‘Run As’ user.

Install the plugin on your TeamCity server, give it a try, and let us know what you think about it.

Happy building!

The TeamCity Team

Posted in Features, FYI, How-To's, Tips&Tricks | Leave a comment

TeamCity 2017.1.4 bugfix is released

Greetings, everyone!

Here is another update to our latest released version: please welcome the TeamCity 2017.1.4, a bugfix release addressing about 90 issues.

We recommend upgrading as this version contains a few performance and security fixes. The details are available in our release notes.

TeamCity 2017.4 data format is the same as that of all the 2017.1.x releases enabling you to easily downgrade if required, so just download the new version and install it on your server.

We’ll be happy to get your feedback: feel free to use our forum and issue tracker.

We are also working on the TeamCity 2017.2 EAP: follow our news for the latest features available in the preview version.

Happy building!
The TeamCity Team

Posted in Bugfix, Release | Leave a comment

TeamCity 2017.2 EAP2 is out

Greetings, everyone!

We are happy to present the new EAP version of TeamCity 2017.2 to you.

In TeamCity 2017.2 EAP2 we are introducing a new feature – composite builds allowing to aggregate results from several other builds connected by snapshot dependencies and presents the results in one place. A composite build can be viewed as a build which consists of a number of parts which can be executed in parallel on different agents. All these parts will have synchronized snapshot of the source code and the results can be seen in a single place. We would really like you to try this feature and share your feedback with us.

This EAP build also comes with improved Docker integration: you can now create a connection to a docker registry and TeamCity will be able to automatically log in to the specified registry before a build and log out of the registry after it. You can now instruct TeamCity to remove the published images during the build clean-up, and more.

Plugins management improvements include tracking newly uploaded plugins and disabling them via the web UI.

For the full list of improvements, see our release notes.

Download TeamCity 2017.2 EAP2 and make sure you install it on a trial server: this version is still in development; besides, it modifies the TeamCity data format making the downgrade impossible.

Try the new version and help us make it better: our forum and tracker are always at your disposal.

Happy building!
The TeamCity Team

Posted in EAP, Features, Uncategorized | Leave a comment

Build React Apps with TeamCity

Greetings, everyone!

In this blog post we will talk about building a React application with TeamCity using one of the newest TeamCity features –  Docker integration, introduced in  TeamCity 2017.2 EAP1. (At the moment the TeamCity-Docker support can run on Mac/Linux build agents).

We’ve created an example on GitHub based on Create React App and Storybook, and set up a demo project on the public TeamCity server with the VCS Root pointing to the project on GitHub.

We used the Command Line build step for our build configuration.

Command Line Build Step

We are going to execute the following script:

#!/bin/bash
set -e -x

yarn
yarn test-ci
yarn build
yarn build-storybook

Here yarn is used for installing dependencies and running scripts, but it is possible to use npm as well.

Our command line will run in a docker container – in TeamCity 2017.2 EAP the Command Line runner settings have the Docker settings section where you can specify the image for the container:

TeamCity will start the container and run this build step in it. node:latest in the Docker settings section stands for Docker’s official node image):
buildStep

Report tabs

test-ci in our script runs tests with the jest-teamcity-reporter plugin (see this commit).
In the line react-scripts test --env=jsdom --coverage --testResultsProcessor=jest-teamcity-reporter, the --coverage option turns on generating a code coverage report, which will be displayed in a dedicated build tab. TeamCity has the report tabs feature, and on our server the Root project – the parent of the demo project – has a predefined Code Coverage tab which expects the report to be at coverage.zip!index.html:
rootCodeCoverage

All we have to is specify the artifact path coverage/lcov-report => coverage.zip in the General Settings section of our build configuration:
artPaths
We also added the artifact path for the build directory (build => build), so that it is available in the artifacts and can be deployed to some server later, which is out of scope for this post.

After running the build, the Code Coverage report is available on the build results page.
Screen Shot 2017-08-23 at 04.22.29

In our build the build-storybook script generates a living style guide for your component base using Storybook. It will be handy to use another build tab to display it, so the storybook-static => stories artifact path has been added. Then we set up a custom tab in the “React App” project settings using the Report tabs section:
reportTab

Note that this Stories tab available on the build results page is generated per build, so you can see how your components change over time and, for example, detect at which point something started looking and/or behaving in a strange way.
Screen Shot 2017-08-23 at 04.17.55

Your feedback is always welcome in our forum and tracker!

Happy building!

Posted in EAP, Features, How-To's, Tips&Tricks | Leave a comment

Welcome TeamCity 2017.1.3 Update

Greetings, everyone!

Today we are releasing the TeamCity 2017.1.3 update, containing bugfixes and refinements to the new features that were added in TeamCity 2017.1.

This update brings over 100 fixes, including:
– a few NuGet-related fixes
– a number of performance and security improvements

For details on all the enhancements available in TeamCity 2017.1.3, please see our release notes.

As usual, this update uses the same data format as all 2017.1.x releases, and we recommend that you upgrade to the latest version – should the need arise, you can roll back to a previous version.

Our forum and tracker are at your disposal and awaiting your feedback on the new version.

Not only have we been fixing bugs in the latest version, but we have also been working on the new one – so stay tuned for the news on the TeamCity 2017.2 EAP.

Happy building!

The TeamCity Team

Posted in Bugfix, Release | Leave a comment

Manage TeamCity Users with Invitations Plugin

Managing users of a TeamCity server is one of the tasks currently handled by the server administrator. Now when a new user comes to the company, they need to create an account on a TeamCity server (provided the default setting allowing users to register on the first login is enabled). Next, registered users need to ask the TeamCity server administrator or a Project administrator to grant them the required permissions.

Invitations Plugin Overview

The open-source Invitations plugin from JetBrains enables TeamCity administrators to invite users to create or join TeamCity projects. Typically this task will be handed over to Project administrators: they will create a project and will be able to send out invitations to the project users with the permissions scope already defined, thus freeing the System Administrator from granular permissions assignment and saving the new users the time and effort currently required for registering on the server.

It is possible to restrict the invited users’ access to a definite project (or several projects): in this case the per-project authorization mode is required on the server. This way any invitation will limit the user access to the project the invitation is sent from.

The plugin is compatible with TeamCity 2017.1 and later.

Installing Plugin

System Administrators can download the Invitations plugin.zip from here and install it on the TeamCity server as usual.

Using Plugin

The use of the plugin is quite straight-forward: after the server restart, the plugin adds the Invitations page to the settings of all projects on the server.

To invite users:

  1. Go to the Project Settings | Invitations page and select the invitation type:
    createInvite

    Invitation Types

    Two types of invitation are supported.
    The invitation to create a project will grant the invitee the Project Administrator role. Note that if per-project permissions are not enabled on the server, any project administrator will get access to TeamCity server administration.

    The invitation to join a project allows the project administrator to define a role for the invitee as well as the group they will be added to. The available roles depend in the roles configuration on the server.
    As for groups, the invited users can be added to any group having ‘View project’ as the minimal permission in the current project.

  2. Next create your invitation:
    • modify the automatically filled in fields as required,
    • specify whether the invitation will be used multiple times (default), or once, after which it will be removed from the UI,createSubproject
    • save the invitation.
  3. The invitation has been created. Copy the invitations link and sent it to the user you want to invite.
  4. The user will follow the link, register or log in to TeamCity, after which they will be able to create / join a project on the server.Invite

That’s it. We hope you will find this plugin useful. Your feedback is greatly appreciated!

Happy building!
TeamCity Team

Posted in Features, Tips&Tricks | Leave a comment