We continue working on TeamCity 2019.2, and you can be the first to try some new features in this second EAP.
Since this EAP:
TeamCity provides server metrics in a popular Prometheus format, ready for monitoring on visual dashboards like Grafana.
Updates in experimental UI: access the Favorite Projects page from the sidebar, see the reason behind the queuing behavior for each build, and use the revamped Changes pop-up menu.
Our REST API provides the same information about cloud integration as that available in the TeamCity UI.
Kanpur 2019.2 EAP2 resolves over 100 issues. See the full list of fixes and features in our release notes.
Remember that the new release changes the TeamCity data format and downgrading to the previous production version is not supported. We recommend installing this EAP version on a trial server. If you installed the previous TeamCity EAP version, you can easily upgrade with our automatic update. In other cases, you can download the EAP build or pull the Docker image with the eap tag.
On July 24, 2019, a security researcher reported a security vulnerability in JetBrains TeamCity. The vulnerability allows cross-site scripting (XSS) on many pages, potentially making it possible to send an arbitrary HTTP request to the TeamCity server under the name of the currently logged-in user. The vulnerability affected TeamCity versions 2019.1 and 2019.1.1. It was fixed in TeamCity 2019.1.2.
What information was compromised
This security issue affected all TeamCity installations of versions 2019.1 and 2019.1.1, possibly allowing an unauthorized person to execute code remotely.
We do not have any information to confirm whether your particular TeamCity installation was compromised or not.
What actions we’ve taken
We resolved the issue as a regular XSS on July 18, 2019, and released the build of TeamCity with the fix on July 31, 2019. We are also adding automated tests to check for this type of vulnerabilities whenever changes are deployed to the codebase.
What actions you should take
Please upgrade to the latest build from our website.
Note: if you’re using a TeamCity version older than 2019.1, you’re not affected by this particular XSS. However, from a security point of view, upgrading to 2019.1.2 is still recommended because TeamCity 2019.1 contains other security fixes.
If you have any questions, please contact our Support. Please note that because of the nature of the vulnerability, we will not be able to disclose any details of how it can be exploited as this can affect other TeamCity installations.
We have just released TeamCity 2019.1.3: this bugfix update resolves 50 problems.
Some users were facing issues with how the Pull Requests build feature handles old and reopened pull request branches. Now, builds will run properly on such branches and new commits will be consistently detected in them.
To prevent Linux file permissions conflicts for the Docker Compose step, if a build with this step is running on a Linux agent, it will now try to restore the ownership of files under own directories for the user who launched this agent (even if the build was interrupted).
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.
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 the numbers for failed, ignored, and muted tests.
If we choose a single build and navigate to the build overview page, we will see some more data. For instance, for build number 14 we can see that there are 39 passed tests, and 1 test (system.CrashControllerTests) is ignored.
Further on, the Tests tab displays the full list of the tests that were executed:
It is possible to use the controls at the top of the list for grouping and filtering the results. Since TeamCity preserves the history of the tests, we can also see the historical data for their duration:
The duration is associated with the build agent on which the test was executed. The graph immediately shows us whether any agents are performing poorly for the specific test. We may want to fix something in the environment for that agent, or we can also exclude the agent entirely for this build configuration by adjusting the Agent Requirements.
Flaky test detection
Sometimes, seemingly at random, the same test of the same code will produce diﬀerent results. We call those tests flaky. Flaky tests can be caused by various factors: environment affecting the test or application code, concurrency issues, etc.
It’s really great if we can detect such unstable tests sooner and fix them faster. Analyzing the historical test reports manually to find out, if there are any flaky tests would take ages. TeamCity detects flaky tests and displays them on the dedicated tab for a given project.
For every single test, we can view the history, assign an investigation, or temporarily mute the failure. For instance, we can mute all the flaky tests for the duration while someone is fixing them. Muting the tests will allow the build to pass so that the build chain can continue the execution. Once the tests are fixed, we can unmute them again.
Here’s an example of a flaky test. At the screenshot below, we can see that the test status was changing from passed to failed and back a few times, even though there were no related changes in the version control. Hence, the test was marked as flaky so that we could easily find it in the test report.
The test results are associated with the build agent which helps to diagnose the failures better. For instance, the test might be failing only on a specific build agent. Then maybe the failure is related to the environment and not the test logic itself.
Code coverage is a combination of metrics that measure how your code is covered by unit tests. To get the code coverage information displayed in TeamCity for the supported tools, first we need to configure it in the dedicated section of a Build Runner settings page.
For instance, for Maven build step, at the bottom of the configuration page, we can find the Code Coverage section. We can choose the code coverage runner and specify which binaries should be inspected.
After the test execution, the coverage metrics are presented on the build overview page. We can view the full report on the Code Coverage tab.
Metadata in tests
Sometimes you need to provide more data with the test results. For instance, include a screenshot, add some numeric data, or just provide any description. This is useful when we need to analyze why the test failed and any additional information can help save precious time.
In TeamCity, a test may be associated with some information – the metadata. The types of data that we can associate with the test is text, numeric values, images, and files that are published as build artifacts.
We can use service messages to associate the data with the test. The data is then rendered with the test results:
For more about metadata in tests, read this blog post.
Risk group tests re-ordering
A test suite with a large number of tests takes some time to execute. Sometimes, for large suites, the execution time can be many hours. What if the very last test fails and we want to rerun the test suite? Would we need to wait a few more hours just to learn that the same test fails again? Instead, it would be nice to run the recently failed tests first.
Here comes the first Early Access Preview (EAP) build of TeamCity 2019.2! Our work on the next version of TeamCity is in full swing, and we are ready to give some sneak peek at what’s in progress.
There’s good news for those who use Amazon EC2: TeamCity now supports Amazon launch templates! When adding an image in a cloud profile in TeamCity, you can select an existing Amazon template to apply the predefined configuration parameters to requested instances.
Another nice feature is code highlighting for scripts of the most popular build runners: Command Line, Ant, Powershell, Docker, NAnt, and Rake, and for the configuration code of Amazon EC2 images.
Dockerfile highlighting in TeamCity
We continue working on our experimental UI: many new features are on their way. In this EAP:
Try the detailed Build Preview directly in the build list.
With the Compare Builds feature, select two builds from the same configuration to review their details side-by-side and get a hint on what might have affected the build behavior.
This EAP also brings optimizations to a multinode setup and Docker integration.
The detailed feature description and the list of fixes are available in our Release Notes.
All our EAP releases come with a 60-day Enterprise evaluation license for an unlimited number of agents and build configurations. As usual, the new release changes the TeamCity data format and, since version 2019.2 is still in development, we recommend installing it on a trial server.
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 your servers. Enter TestDrive!
TestDrive is a limited cloud TeamCity offering. It is a way to try TeamCity for 60 days, without the need to download and install it. TestDrive is currently hosted on top of the teamcity.jetbrains.com server and lets you create one TeamCity project.
This blog post is a getting started guide on how to set up a project in TestDrive.
You will proceed to the login screen of the hosted TeamCity instance. It is possible to register a JetBrains account or log in with any other account that is supported in TestDrive: Google, GitHub, Yahoo!, or Atlassian BitBucket. For instance, if the repository that you are planning to work with is located at GitHub, then it makes sense to log in with a GitHub account.
Creating a project
After the login, the setup wizard will offer a number of options to configure your project. Say, we logged in using a GitHub account. Now the connection with GitHub is created and TeamCity can list all the repositories available on the account. We can just select the repository, and TeamCity will create the project and an initial build configuration.
TeamCity will scan the repository and detect the possible build steps. The steps are backed by the build runners. If TeamCity locates any relevant files that are related to the runner, it will offer to configure a corresponding build step. Such file examples include IDE project files, Dockerfile, pom.xml, gradle.build, shell scripts, etc.
For Buffalo, we only need a Command Line build step to execute the go command.
To make sure that the build runs with the correct version of Go, it makes sense to execute the build step in a Docker container. In the build step configuration, we can specify which image should be used. In this case it’s golang:1.12.
The build is ready to start. We can either start it manually or configure a build trigger to react to the new changes in the repository.
Running the build
To run the build, click the Run… button on the top-right of the screen. The build job will be placed in a queue. While it is waiting, we can see which agents are available to execute the build.
Once a build agent becomes available, the build will start and its status will be updated in real time while it is running. I there are any test failures, the status will indicate the failure long before the build finishes. You can monitor the build progress on the Build Log tab:
Once we have configured the project in TestDrive, it is listed under the account that we used for sign in. We can invite more people to work on that project. To do this, go to the Invitations tab in project settings and create an invitation link.
The invitation includes the correct role that will be assigned to the collaborator when they join the project by using the generated link. In this way, we can create multiple invitations for different roles.
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.
Configuring Golang build feature
To enable Go support in TeamCity, go to Build Configuration Settings | Build Features, click Add build feature, and select Golang from the list.
The Golang build feature enables the real-time reporting and history of Go test results in TeamCity.
Running Go tests
Once the Goland build feature is enabled, TeamCity will parse the JSON output of go test command. Hence, the command should be executed with a -json flag using one of these two methods:
Add this flag to the Command Line build runner’s script: go test -json
Add the env.GOFLAGS=-json parameter to the build configuration
In fact, since a lot of Go projects are actually using make to build the code and execute the tests, it will require changing the Makefile respectively:
The build feature is enabled and a -json argument is added to the go test command. We can now execute the build configuration. As a result, TeamCity will record data about the test execution status, execution time and present this data in the UI.
For each individual test, it is possible to review its execution time from a historical perspective across different build agents where the test was executed.
Muting the failing tests
Assume that there are 248 tests in our project and 4 of those tests are failing. Meaning, the build does not succeed. However, we know that it is okay for those tests to fail and we would like to temporarily “mute” the specific test failures in the project. TeamCity provides a way to “mute” any of the currently failing tests so they will not affect the build status for future builds.
Muting test failures is a privilege of the project administrator. Select the individual failed tests in the build results and click the Investigate/Mute button that appears at the bottom of the screen. It is then possible to mute the tests either project-wide or just in the selected build configuration. The unmute policy can also be specified. For instance, once the test is fixed, it will automatically unmute.
But what does muting the test failure has to do with running Go tests? We use the go test command to execute the tests, and its exit code depends on the status of the execution. If there is even a single test failure, the exit code will be 1. The build will fail since the Command Line build step in TeamCity aims to respect the exit codes.
To mitigate this issue, we just have to make sure that the exit code of the last command in the Command Line runner (or a build script) is 0. For instance, by executing an exit 0 command in the build step (or in the Makefile). In this case, it will be possible to mute the failures and make the build configuration succeed. If the exit code is 0 but there are still test failures that are not muted, then TeamCity knows that it has to fail the build.
Support for Go is provided by TeamCity out of the box, there are no external plugins required. TeamCity parses results of go test command execution. The results are persisted and it is possible to review the figures in a historical perspective. Consequently, all the TeamCity features that are related to test reporting are now available for Go developers.
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 Publisher build features. And finally, we’ll see how it all comes together when building pull request branches.
Setting up a VCS root
First, let there be a VCS root in a TeamCity project. We can configure the VCS root in Build Configuration Settings | Version Control Settings and click Attach VCS root.
When setting up the VCS root we have to make sure that the branch specification does not match the pull request branches.
The branch specification in the screenshot above includes a +:refs/heads/feature-* filter. This means that any branch in the GitHub repository that starts with feature-* will be automatically detected by this VCS root. A pull request in GitHub is a git branch with a specific naming convention: refs/pull/ID/head, whereas the ID is the number of the pull request submitted to the repository.
It is possible to configure the VCS root to match the incoming pull request branches and TeamCity will start the builds automatically. However, you might want to restrict the automatic build triggering for these branches. Hence, it is better to avoid adding +:* or +:refs/pull/* patterns to the branch specification of a VCS root. Instead, we can use the Pull Requests build feature to gain more control over the incoming pull requests.
Configuring Pull Requests build feature
Pull request support is implemented as a build feature in TeamCity. The feature extends the VCS root’s original branch specification to include pull requests that match the specified filtering criteria.
To configure the pull requests support for a build configuration, go to Build Configuration Settings | Build Features, click Add build feature, and select the Pull Requests feature from the dropdown list in the dialog.
We can then configure the build feature parameters: select the VCS root, VCS hosting type (GitHub), credentials, and filtering criteria.
The Pull Requests build feature extends the branch specification of the related VCS root. As a result, the full list of branches that will be visible by the VCS root will include the following:
The default branch of the VCS root
Branches covered by the branch specification in the VCS root
Service-specific open pull request branches that match the filtering criteria, added by Pull Requests build feature
For GitHub’s pull request branches we can configure some filtering rules. For instance, we can choose to only build the pull requests automatically if they are submitted by a member of the GitHub organization.
In addition to this, we can also filter the pull requests based on the target branch. For instance, if the pull request is submitted to refs/head/master then the pull request branch will be visible in the corresponding VCS root. The pull request branches whose target branch does not match the value specified in the filter will be filtered out.
Publishing the build status to GitHub
For better transparency in the CI workflow, it is useful to have an indication of the build status from the CI server next to revision in the source control system. So when we look at a specific revision in the source control system we can immediately tell if the submitted change has been verified at the CI server. Many source control hosting services support this functionality and TeamCity provides a build feature to publish the build status into external systems, the Commit Status Publisher.
The build status indication is useful when reviewing the pull requests submitted to a repository on GitHub. It is advisable to configure the Commit Status Publisher build feature in TeamCity if you are working with pull requests.
Triggering the builds
The Pull Requests build feature makes the pull request branches visible to the related VCS root. But it does not trigger the builds. In order to react to the changes detected by the VCS root we need to add a VCS trigger to the build configuration settings.
To add the VCS trigger to a build configuration, go to Build Configuration Settings | Version Control Settings, click Add new trigger, and select the VCS trigger from the list.
The default value in the branch filter of the VCS trigger is +:*. It means that the trigger will react to the changes in all the branches that are visible in the VCS roots attached to the same build configuration. Consequently, when a pull request is submitted, the trigger will apply and the build will start for the pull request branch.
Building pull requests
Once the Pull Requests build feature is configured we can try submitting a change to a GitHub repository:
When the new pull request is created, we can choose the branch in the target repository. This is the branch we can filter in the Pull Requests build feature settings in TeamCity.
Once the pull request is submitted, TeamCity will detect that there’s a new branch in the GitHub repository and will start the build.
The build overview page in TeamCity provides additional details about the pull request.
The build status is also published to the GitHub repository by the Commit Status Publisher:
Here is a short screencast demonstrating the process above:
Now the puzzle pieces are coming together. The Pull Requests build feature extends the branch specification of the VCS root to match the pull request branches. The VCS trigger detects that a new pull request was submitted to the GitHub repository and triggers the build. Once the build is complete, the Commit Status Publisher sends the build status back to GitHub.
The Contest is over and we want to say a huge Thank You to all the participants for making it a resounding success!
For the past couple of weeks, our judges and members of the TeamCity team have been hard at work trying out, testing, and rating plugins submitted to the Contest. Every submission was judged against four main criteria: usefulness, creativity, completeness, and code quality.
The finalists were really close, which made our judges’ task that much more challenging. After a lot of deliberation and discussion, the list of winners was determined at last:
Award: 1-year subscription to the All Products Pack and 1 TeamCity Build Agent license
Congratulations to the winners! We will be contacting you shortly after this announcement to deliver your prizes.
We are grateful to everyone who participated for all the efforts you have put into developing and finalizing your plugins! Thanks to you, the following 15 plugins are now publicly available in our Plugin Repository: