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:
This guest post is brought to you by Harshit Paul, a Content Specialist at LambdaTest.
TeamCity now offers integration with LambdaTest, a cloud-based cross-browser testing tool offering automation with Selenium Grid. LambdaTest offers a library of 2000+ real browsers for both mobile and desktop devices. Serving more than 60,000 users every year, LambdaTest is one of the fastest-growing cross-browser testing clouds.
Why are developers & testers fond of LambdaTest?
Selenium API – LambdaTest offers an Open API for their Selenium Grid, empowering their users to extract test reports of the script executed on their platform. You can extract these reports from LambdaTest’s cloud to your preferred storage facility, even without logging in.
Intuitive Test Logs – Offering a neat & organized automation dashboard, LambdaTest provides great visibility over your automated Selenium test scripts. You can find details such as timestamps, test status, network logs, command logs, Selenium logs, metadata, and more.
Native Built-in Dev Tools – LambdaTest offers developer tools for every possible browser included in their platform.
Parallel Testing – LambdaTest offers an easy-to-scale Selenium Grid where you can perform multiple Selenium test scripts, simultaneously.
Test Locally Hosted Web Pages – You can ensure how well your website will look after every code change, by performing cross-browser testing of locally hosted web pages or web applications using an SSH tunnel termed as Lambda Tunnel.
Numerous Third-Party Integrations – You will find various third-party integrations with project management tools, instant messaging platforms, and continuous integration & continuous deployment tools such as TeamCity.
One-Click Bug Logging – Highlighting bugs and sharing them with colleagues are often a tedious task. Well, not if you are using LambdaTest: it offers a built-in image editor which helps you highlight a bug and share it with your colleagues or on the project management tool’s dashboard in one click, thanks to the LambdaTest integrations.
24/7 Customer Chat Support – If you ever come across any issue related to platform usage, or any suggestions regarding the product, you can simply give the support team a shout through the chatbot and expect a response in under a minute.
How can TeamCity integration with LambdaTest help your continuous testing workflow?
TeamCity’s integration with LambdaTest will empower you with continuous integration, continuous deployment, and continuous testing.
Test your code commits before migrating them to the Production – As you commit changes to your project, you can have them tested over different browsers by performing cross-browser testing with LambdaTest through their Selenium Grid & SSH(Secure Shell) tunnel. The SSH tunnel establishes a secure connection between your system and LambdaTest cloud servers, allowing you to host your local web pages on their virtual machines. That way, you can see how your code changes will affect your website’s UI when accessed through various browsers.
Faster automated cross-browser testing & faster CI CD pipeline – The primary purpose of automation testing is to cut short the time & effort of your routine test cycles. However, the sequential execution of test scripts can be very time-consuming. Parallel testing with LambdaTest Selenium Grid will help you overcome the drawback of sequential execution as you will be running multiple Selenium tests simultaneously. By using TeamCity along with LambdaTest Selenium Grid, you can have a faster pipeline and rapid test validation for browser compatibility of your latest release before making it live.
Test & push hassle-free, from anytime, anywhere using cloud – LambdaTest & TeamCity both offer an entire CI CD & test solution on the cloud. That means you can get rid of the hassle that often comes with setting up the infrastructure and maintaining it. LambdaTest gives you access to real mobile and desktop browsers. You get a variety of desktop devices including operating systems for both Windows and Mac. For mobile testing, you can select from Android and iOS devices. You could also test on tablets and iPads to ensure how responsive your website is turning out to be after the last code commit.
Open API to help you customize your user experience – Both LambdaTest & TeamCity offer Open APIs. TeamCity’s Open API allows you to create your own custom plugin if none of the hundreds of plugin offered is suitable for your project. LambdaTest offers an open Selenium API to help you extract Selenium test reports from LambdaTest to your preferred storage without logging in to the platform.
Reliable scalable architecture and licensing – Both LambdaTest and TeamCity provide a secure and robust platform which you can scale according to your project requirements. You can start using the product with free licensing and scale later as your project demands grow. With TeamCity, you can expand server capacities as you like; with LambdaTest, you can increase the number of concurrent sessions to help run more test cases in parallel.
All you need to do is declare the Selenium script while configuring a build on your TeamCity instance, along with environment variables specific to LambdaTest authorization, and you are good to go.
Running your first Selenium script on LambdaTest from your TeamCity project
Step 1: Create a new project and add a new VCS routing to Git repository. Here is a sample git repository to help you run your first Selenium script using Protractor.
Step 2: Create build configurations and go to the Build Step page to enter the below command as your script for running a single test script. Powershell -Command “protractor conf\single.conf.js”
Similarly, if you wish to run multiple tests in parallel, then run the below script: Powershell -Command “protractor conf\parallel.conf.js”
Step 3: Save your build step and provide the LambdaTest username and access key as the environment variable for authenticating your LambdaTest account with the TeamCity instance.
Step 4: Run your project from the Project dashboard.
It’s time to build the future
Together with LambdaTest, we’re committed to simplifying your continuous testing workflows so that you can focus on making innovative products and solve real-world problems, rather than merely testing older ideas.
What do you think of this integration? Let us know in the comments section.
The TeamCity Plugin Contest has entered its final chapter as we yesterday closed the door to any more plugin submissions. We would like to thank every one of the participants who spread the word, joined the contest, and spent their valuable time developing new plugins. Thank you all – we really appreciate your efforts!
Of the 89 developers registered for the contest, 15 submitted valid plugins, each of whom have received a 1-year subscription to a JetBrains IDE of their choice. Congratulations!
Submissions for the contest are now closed, and so begins the judging and voting for the best plugin. You can review all the submitted plugins and vote for the ones you like the best. The author of the most voted plugin will receive the People’s Choice Award.
This release fixes over 100 issues including several performance problems. Notably, these fixes have affected:
New experimental UI
We have also addressed the recent changes in the Bitbucket REST API and improved TeamCity Bitbucket cloud connections accordingly. You can find the full list of fixed issues in our Release Notes.
We recommend upgrading to version 2019.1.1 to benefit from all the latest improvements. This new version uses the same data format as 2019.1 release which makes it easy to upgrade/downgrade within these builds.
If you’re already participating, we’ve just added a couple of new articles in our Plugin SDK documentation to make your life a little easier:
The first one describes different approaches to how the plugin state and plugin settings can be stored in TeamCity. This is a very common task but unfortunately was not described at all up until this point.
We plan to continue adding new topics to our Plugin SDK documentation. We also welcome your ideas on what could be described better or what you think is missing in our documentation.
By the way, the TeamCity Plugin SDK documentation is now located on GitHub: https://github.com/JetBrains/teamcity-sdk-docs. If you notice a mistake or anything incorrect there, feel free to create a pull request or submit a bug report.