TeamCity Plugin Contest: submissions are closed, you can now vote for the plugins

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!

TeamCity Plugin Contest 2019_e-mail-03

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.

Vote for plugins

We will announce the five winners on July 17.

So fingers-crossed, be patient, and don’t forget to pick your favorite plugins. Follow our blog or twitter for the winners’ announcement.

Thanks again and happy building!

Posted in Contest, Plugin development | Tagged , | Leave a comment

TeamCity 2019.1.1 is here

TeamCity 2019.1.1 is available!

This release fixes over 100 issues including several performance problems. Notably, these fixes have affected:

  • New experimental UI
  • Multinode configuration
  • Kotlin DSL

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.

You can select any of these upgrade options:

Remember to check our Upgrade Notes to make sure your upgrade to TeamCity 2019.1.1 goes smoothly.

You can leave feedback in our forum or tracker.

Happy building!

Posted in Bugfix, Release | Leave a comment

New topics in Plugin SDK documentation

The TeamCity Plugin Contest is ongoing and there is still enough time to write some cool plugins!

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.
  • The second one describes how build features can be implemented. Sometimes you just want to affect how a build behaves, and this behavior change can’t be represented as a step, because steps follow a strict order. Build features can come handy in this case. Examples of build features in TeamCity are XML report processing, Build files cleaner, and File content replacer.

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.

Posted in Plugin development | Leave a comment

14 Cool TeamCity Plugins You Can Start Using Right Now

While TeamCity provides a lot of functionality out of the box and bundles a number of plugins in its distribution package, there are still use cases where you might need something extra. In this blog post, we are going to list 14 cool plugins that add new features or integrate with external tools. The plugins are not bundled with TeamCity in the distribution package but can be easily installed from the JetBrains plugins repository.

First, let’s take a look at the plugins that add new functionality to TeamCity for a very specific task in your build process. It could be a plugin that adds in integration with a build tool, provides a specific build step or a build feature, a UI extension, and so on.

Agents priority is a very nice plugin developed as part of our previous TeamCity Plugin Contest. The plugin lets you order TeamCity build agents by different criteria. Whenever a build starts, an available agent with the highest priority will be used.

tc-agents-priority

AutoProperties provides a build feature that can set parameters based on whether the build was triggered by a user. It can also set different parameters depending on those that exist already. The plugin will run before any build steps are executed, so the updated parameters will be immediately available.

The Gradle Build Cache plugin applies the Gradle Hazelcast settings plugin to enable remote build caching, and starts a Hazelcast node on the TeamCity server. This should make your Gradle builds run faster – very useful!

REST runner is also one of the plugins developed during the previous TeamCity Plugin Contest. It adds a build step that allows you to execute an HTTP request to an external service and handle the response using a Groovy script.

TeamCity OAuth is a lightweight alternative to the functionality provided by JetBrains Hub, enabling GitHub or generic oAuth2 authentication for TeamCity.

The SSH Tunnel plugin adds a build feature that allows SSH tunnels to be opened with port and socket forwarding. After adding the build feature to a build configuration, the plugin opens the configured SSH tunnels before the build starts, and any step in the build can use the established forwards.

Now for something different… Achievements is a fun feature that grants TeamCity users various badges based on their activities. The badges are displayed at the top of the screen, next to the user’s name. Here are a few examples:

  • Novelist – Granted for extra long commit descriptions.
  • Debugger – Granted for a series of commits mentioning fixed bugs.
  • Big Brother – Granted for assigning investigations to several different persons.
  • Boy Scout – Granted for assigning several investigations for a test or problem to himself.
  • … there’s more!

tc-achievemnts

Use the Achievements plugin to add some fun in your CI experience! 😉

The Invitations plugin lets you invite users to create or join TeamCity projects. We use this plugin at the test hosted TeamCity instance to simplify collaboration for users.

Kubernetes support is a plugin that allows TeamCity cloud agents to run in a Kubernetes cluster and provides a ‘Helm’ build step.

The Rust plugin for TeamCity enables you to build Rust programs with Cargo. The plugin detects the Cargo.toml configuration file once you add a VCS root to the Build Configuration, and suggests the corresponding build steps.

Bazel plugin adds a corresponding build step and integrates with the core functionality of TeamCity. This includes auto-discovery of build steps, Bazel tool detection on build agents, and cleanup of Bazel workspace caches. It also adds a build feature for Bazel’s remote cache in order to speed up your builds.

You can find many more interesting TeamCity plugins in JetBrains Plugins Repository. What’s more, you can become a plugin author – and the ongoing TeamCity Plugin Contest is a great opportunity to try your hand at this! So if you feel you’re up to it, hurry and apply!

Now, let’s look at another category of plugins that provide integration with external services to enhance your CI/CD pipeline.

A proper CI/CD pipeline today poses requirements that go beyond the traditional build process. This includes steps for security scanning, managing binaries, running deployment tasks, managing environments, working with the reports produced by the build server, and much more. For many of these activities, there are services or tools that integrate nicely with TeamCity. Here are a few interesting tools that will help you build a sophisticated CI/CD pipeline in collaboration with TeamCity.

The Snyk plugin adds the ability to test your code dependencies for vulnerabilities against the Snyk database. When you use the Snyk plugin in TeamCity, the build process makes sure that it is in line with the Snyk org’s rules. The build will fail if the security scan detects that the code is vulnerable beyond what the policy allows.

As a result of a build process in TeamCity, we often produce binary artifacts that can stay in the build server. However, there are products tailored for working with binaries which are definitely worth using for managing your artifacts. Artifactory is a tool designed to work with binaries, and the Artifactory plugin for TeamCity makes the integration possible.

Beyond managing the efficient deployment of your artifacts to Artifactory, the plugin lets you capture information about artifacts deployed, dependencies resolved, environment data associated with the TeamCity build runs and more, that effectively provides full traceability for your builds. (link)

Not only do we produce and manage the binaries in the CI/CD process, but we also need to somehow deliver the artifacts into the environment to serve the business. Octopus Deploy is a convenient tool for delivering software packages to the servers.

The Octopus Deploy plugin for TeamCity integrates with the Octopus Deploy server in order to deliver NuGet, zip, tar, gzip, tar, bzip2, jar, war, ear and rar packages for deployment. TeamCity builds the packages and runs tests, and then Octopus Deploy takes those packages and pushes them through the development, test, and production environments.

OD

We recently hosted a webinar about using Octopus Deploy with TeamCity and the recording is available for you to watch.

As you can see, there are plenty of interesting plugins for TeamCity tailored to many specific use cases. I would venture a guess that you, too, may have a particular use case that stands to be implemented via a plugin. Fancy having a go at it? There’s still time left, so apply for the TeamCity Plugin Contest, submit your solution, and win the day!

Posted in Blogroll, Contest | Tagged | Leave a comment

TeamCity 2019.1: New UI, GitLab Integration, Support for Go, Token-Based Authentication, AWS Spot Fleet Requests

Please welcome TeamCity 2019.1—the first major release of this year! TeamCity 2019.1 provides a redesigned UI, native GitLab integration, and support for GitLab and Bitbucket server pull requests. Also included are token-based authentication, detection and reporting of Go tests, faster build agent upgrades, and AWS Spot Fleet requests.

800x418_Twitter_card_release @2x

Here are the key new features of the release.

New look, new feel, fewer clicks

TeamCity UI is getting a major overhaul, and here’s a first taste of what you’re going to get in this version.

Not only have we improved the look, but we’ve also updated the underlying technology stack so now the UI works as a single-page application, which means you can access parts of it faster and all the changes appear instantly. See the full TeamCity UI roadmap to stay up to date with all the planned changes.

In 2019.1, we are targeting the pages related to working with projects and build configurations.

screen1@2x

The new sidebar provides easy access to your builds and projects. The quick search lets you navigate to other build-related pages.
The project overview has been completely reworked and now provides a dashboard-style view over your build configurations.
The reworked Branches tab on the build configuration overview now displays your default branch, increasing the visibility of the most important data.

branches@2x

Full GitLab support out of the box

Using GitLab? TeamCity 2019.1 adds full support for GitLab. You can now set up a GitLab connection and create projects in TeamCity with one click, by simply picking a GitLab project from the list.

We’ve also added support for GitLab merge requests, so you can now set TeamCity up to automatically run the build on each merge request and then automerge it if the build is successful.

Go the distance

The Go language is now supported natively by TeamCity. Add your Go projects and TeamCity will detect and report Go tests, providing rich insights into the test status, its history across the builds and its duration, and will mark unstable tests as flaky.

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 useful for REST API authentication.
token-based-authentication

Snapshot dependencies without sources synchronization

You can now set up TeamCity to trigger snapshot dependencies so that it does not synchronize the revisions of code. This is handy when running deployments and lets you promote one of the older builds in the chain using the latest deployment configuration.

AWS Spot Fleet requests

With this more flexible way of creating Spot Instances, you now have more granular control over your Spot Fleet. TeamCity 2019.1 lets you submit and edit the spot fleet configuration file and specify the strategy, set the target capacity, and add tags to your instances. It is a more advanced and cost-effective way of running your builds on AWS.

aws-spot-fleet

Processing build lifecycle on a secondary node

The secondary node now has an additional responsibility: processing the build lifecycle. If you turn it on, the secondary node will handle the build-related tasks, such as running and finishing builds, uploading artifacts, and failure conditions processing. This change expands the already broad list of tasks that you can offload from your main server onto a secondary one: collecting changes from agents, serving as a read-only backup node, and now, processing the build lifecycle.

secondary-node

On-demand tools loading

Tools will now only be loaded onto agents on demand. The necessary tools will be loaded only when the first build requiring them appears. This significantly improves the build agent upgrade times and saves you network traffic.

There is more to this release! See the detailed description of these and other features in the What’s new section in our documentation.

Download TeamCity 2019.1

Please check through the upgrade notes before you install the new version, and do not hesitate to report any issues in our tracker or ask questions in the forum.

Posted in Features, Release | Tagged , | 8 Comments

TeamCity 2019.1 RC has arrived

The release candidate for TeamCity 2019.1 is here with some new exciting features:

  • Using snapshot dependencies without synchronizing revisions
  • Support of BitBucket pull requests
  • GitLab connections
  • Faster agents upgrade
  • Delayed auto-assignment of investigations for flaky tests
  • Separate Maven artifact repository for all builds on an agent
  • Branch filter for version control settings of a build configuration

We have also optimized the TeamCity performance to speed up the startup of main and secondary servers.

Read more about all these changes in our release notes.

This RC build fixes over 100 issues listed in our issue report.

To download TeamCity 2019.1 RC, use the automatic upgrade feature or download the latest build and install it as usual. This build is an interim release so we recommend you to experiment with it on a trial server.

The TeamCity RC builds come without the EAP license but the license for the 2019.1 EAP 3 release is valid for this RC.

We are always glad to receive your feedback in our forum or tracker.

The new TeamCity version is on its way!

Happy building!

Posted in EAP, Features, Release | Leave a comment

Webinar Recording: Turbocharging TeamCity with Octopus Deploy

The recording of our May 14 webinar, Turbocharging TeamCity with Octopus Deploy, is available on the JetBrains YouTube channel.

In this webinar, Derek Campbell showcases how to integrate TeamCity and Octopus Deploy. He starts off with building a solution in TeamCity and takes you through deploying it to Development, Test, and finally to Production environments.

DerekDerek Campbell has worked across the world in London, Melbourne, Singapore and now from home in Glasgow, Scotland, for Octopus Deploy as a CI/CD Architect in the Customer Success team. Derek works with and helps Octopus Deploy’s biggest clients like ASOS, AON and L’Oreal with their CI/CD pipeline and helps enable their success with Octopus Deploy.
Posted in Webinar | Tagged | Leave a comment

Configuration as Code, Part 6: Testing Configuration Scripts

In this blog post, we are going to look at how to test TeamCity configuration scripts.

  1. Getting started with Kotlin DSL
  2. Working with configuration scripts
  3. Creating build configurations dynamically
  4. Extending Kotlin DSL
  5. Using libraries
  6. Testing configuration scripts

Given that the script is implemented with Kotlin, we can simply add a dependency to a testing framework of our choice, set a few parameters and start writing tests for different aspects of our builds.

In our case, we’re going to use JUnit. For this, we need to add the JUnit dependency to the pom.xml file

We also need to define the test directory.

In this example, we have redefined the source directory as well, so it corresponds with the following directory layout.

Once we have this in place, we can write unit tests as we would in any other Kotlin or Java project, accessing the different components of our project, build types, etc.

However, before we can start writing any code we need to make a few adjustments to the script. The reason is that our code for the configuration resides in settings.kts file. The objects that we declared in the kts file are not visible in the other files. Hence, to make these objects visible, we have to extract them into a file (or multiple files) with a kt file extension.

First, instead of declaring the project definition as a block of code in the settings.kts file, we can extract it into an object:

The SpringPetclinic object then refers to the build types, VCS roots, etc.

Next, to make this new object visible to the test code, we need to move this declaration into a file with a kt extension:

kotlin-dsl-test-code-in-files

settings.kts now serves as an entry point for the configuration where the project { } function is called. Everything else can be declared in the other *.kt files and referred to from the main script.

After the adjustments, we can add some tests. For instance, we could validate if all the build types start with a clean checkout:

Configuration checks as part of the CI pipeline

Running the tests locally is just one part of the story. Wouldn’t it be nice to run validation before the build starts?

When we make changes to the Kotlin configuration and check it into the source control, TeamCity synchronizes the changes and it will report any errors it encounters. The ability to now add tests allows us to add another extra layer of checks to make sure that our build script doesn’t contain any scripting errors and that certain things are validated such as the correct VCS checkout, as we’ve seen above, and the appropriate number of build steps are being defined, etc.

We can define a build configuration in TeamCity that will execute the tests for our Kotlin scripts prior to the actual build. Since it is a Maven project, we can apply Maven build step – we just need to specify the correct path to pom.xml, i.e. .teamcity/pom.xml.

kotlin-dsl-code-in-ci-pipeline

The successful run of the new build configuration is a prerequisite for the rest of the build chain. Meaning, if there are any JUnit test failures, then the rest of the chain will not be able to start.

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

Building the Snyk Plugin for TeamCity

This guest blog post is brought to you by Brian Vermeer, Developer Advocate at Snyk.

snyk-logo
Snyk offers a developer-first solution for open source security. Snyk is developing a TeamCity plugin to help users with automated vulnerability scanning. Snyk’s blog post series documents their story of building the plugin to help others learn from their experience.

In our previous post (Building open source security into the TeamCity flow with Snyk), we explained our motivation for building the Snyk plugin for TeamCity, and what we aim to achieve with it. As we explained, security is mainly used as a gating mechanism to make sure that whatever doesn’t measure up to policy doesn’t get shipped—but that isn’t always efficient. With Snyk’s plugin for TeamCity, we enable development teams to make the most of security analysis during the development stage, by helping to find and fix vulnerabilities with detailed and actionable insights.

In this follow-up post, we will highlight the Snyk features that we took advantage of when creating this plugin.

Taking advantage of the Snyk CLI

Finding and fixing vulnerabilities in your project’s dependencies is the core business of Snyk. With the Snyk CLI you can run scans on your projects from any machine—even your local development machine. The CLI automatically detects the type of project you have and creates a dependency tree. Snyk validates these dependencies against our proprietary vulnerability database. However, we do not only show whether a particular direct or transitive dependency contains a vulnerability, but also whether there is a possible solution.

For the TeamCity plugin, we use the same existing CLI capabilities to provide you these valuable insights.

We bundled the latest version of our CLI with the TeamCity plugin, which works by calling the CLI binary (embedded in the plugin) for scanning and then returning all key information in a structured JSON file. By default, we provide binaries for macOS, Linux, and Windows so, whatever system your TeamCity instance runs on, there is no need to separately download the Snyk CLI.

Additional capabilities: reporting and monitoring

To present this useful data in a report, we used yet another Snyk tool: the latest snyk-to-html binaries also ship with the plugin for macOS, Linux and Windows. Calling this tool with the Snyk CLI JSON output creates a fancy HTML report displaying all the insights you need to pinpoint and remediate vulnerable dependencies.

The Snyk CLI also enables monitoring your project from the Snyk interface: a snapshot of your dependency tree is uploaded to your Snyk account and then all your dependencies for that specific build are monitored on a regular basis. Additionally, you can enable active alerting (for example by email) so that every time a new vulnerability in your dependencies is found, you receive a notification. This monitoring capability is now also available in the TeamCity Plugin.

Screenshot 2019-04-25 at 14.00.45

How we brought it all together

The plugin introduces a “Snyk Security” build runner, which can be added as a build step in TeamCity.

screencapture-teamcity-demo-tretyakov-me-admin-editRunType-html-2019-05-05-00_14_40

The new TeamCity plugin executes multiple commands and pushes the result forward. With the plugin, users can run snyk test and snyk monitor, ultimately, pushing the test output to snyk-to-html.

We implemented this in the build agent part of the plugin by using a MultiCommandBuildSessionFactory to chain all these commands to the shipped binaries. If everything succeeds then an HTML artifact is produced, which we then made available to the user. The plugin adds the “Snyk Security Report” tab to a finished build page.

Screenshot 2019-05-04 at 19.46.06

A good way to use this step is to run it before deployment and add a snapshot dependency from the deployment build configuration to a configuration which contains the Snyk Security step. You can set it up in a way that if a security scan does not pass a specified threshold, the deployment won’t be started.

Screenshot 2019-05-04 at 20.05.27

Once you fix all the vulnerabilities with the remediation advice that Snyk provides in the report, you are good to go. Make sure that before deploying to production you run a test including snyk monitor. That way, when you ship and deploy that artifact, Snyk continues to monitor it as long as it is in production, and alerts you if new vulnerabilities are found in that build.

Happy coding!

Posted in Contest, Guest post, Plugin development | Tagged , | Leave a comment

Webinar Recording: Getting Started with TeamCity Plugins

The recording of our April 30 webinar, Getting Started with TeamCity Plugins is now available on the JetBrains YouTube channel.

In this webinar, we developed a custom runner plugin for TeamCity. The plugin adds a new build step for the echo command and displays the result of the execution in a custom tab for the completed build. You can find the source code of the plugin on GitHub.

The timeline:

4:23 – Generate project with Maven archetype
8:23 – Create server-side part of the plugin
18:31 – Create agent-side part of the plugin
24:47 – Configure TeamCity SDK Maven plugin
31:13 – Adding configuration UI to the server plugin
33:49 – Adding input validation
54:29 – Display results in a custom tab for the build

Posted in Plugin development, Webinar | Tagged , | Leave a comment