Welcome TeamCity 2019.1 EAP1

We’re excited to announce the Early Access Preview (EAP) for TeamCity 2019.1. Following the tradition, this release is code-named after a gorgeous busy Indian city called Kanpur hinting at elegance and efficacy being the highlights of the upcoming version.

Kanpur 2019.1 EAP1 comes with the revamped user interface and we’re hoping that your experience with TeamCity will now be not only more productive but also aesthetically pleasing.

Our UI comes with a new sidebar, the reworked branches tab, expandable build rows, and the redesigned project overview page. It is still considered experimental, and some pages are not yet available, but you can easily switch between the new and classic UI using the icon in the right-hand upper corner of the screen.

new-ui

Another important feature of this version is the ability to cancel a build from a script using a service message. If needed, you can re-add the build to the queue after canceling it:

##teamcity[buildStop comment=‘canceling comment’ readdToQueue=‘true’]

The detailed feature description and the list of fixes are available in our Release Notes.

As usual, the new release changes the TeamCity data format and, since version 2019.1 is still in development, we recommend installing it on a trial server.

You are welcome to try the new EAP build and share your feedback on our forum or tracker.

Happy building!

Posted in EAP, Features, News & Events | Leave a comment

TeamCity 2018.2.2 is released

TeamCity 2018.2.2 is out today. This bugfix update addresses about 80 issues and brings a number of back-end and front-end performance improvements.

We strongly recommend upgrading as this TeamCity version resolves a few security problems as well. The full list of fixes is available in our release notes.

Like any TeamCity update, 2018.2.2 has the same data format as all 2018.2.x versions, allowing you to upgrade/downgrade within these builds easily.

Remember to check our Upgrade Notes and use one of the upgrade options:

Your feedback is always welcome in our forum or tracker.

Happy building!

Posted in Bugfix, Release | Tagged | 3 Comments

New in TeamCity 2018.2: Simplified Installation of Plugins

Installing new plugins has just become a lot simpler! You don’t have to restart the server to enable a newly uploaded plugin anymore.

The TeamCity server now integrates with the JetBrains Plugins Repository. The new integration simplifies the installation of plugins for TeamCity.

By clicking the “Browse plugins repository” button in your TeamCity server, you will share some information (URL, server id, and version) with the plugin repository. With this information, the plugin repository is able to suggest installing the selected plugin version directly to your TeamCity server. The screencast below demonstrates the plugin installation procedure.

Aside from this, if you have disabled some of the bundled plugins on your TeamCity server, enabling them also does not require a server restart.

It is also possible to enable a periodical check for plugin updates on your TeamCity server. Once any updates are found in the plugin repository, they can be easily installed through the web interface. However, you’ll still need to restart the server to apply the plugin updates.

Aside from this, if you have disabled some of the bundled plugins on your TeamCity server, enabling them also does not require a server restart.

It is also possible to enable a periodical check for plugin updates on your TeamCity server. Once any updates are found in the plugin repository, they can be easily installed through the web interface. However, you’ll still need to restart the server to apply the plugin updates.

TeamCity-newPluginUpd

Finally, there is good news for TeamCity plugin developers. If you develop your plugins with the help of our Maven SDK or the Gradle plugin by Rod MacKenzie, you can benefit from reloading plugins without restarting the server. In addition to this, when TeamCity is started from these SDKs, it will work in a mode where the plugins can be enabled or disabled instantly, also without the need for a server restart.

Posted in Blogroll, Features, Tips&Tricks | Tagged , | Leave a comment

New in TeamCity 2018.2: Show Kotlin DSL for Build Configurations

The Kotlin-based DSL is becoming more popular for defining build configurations in TeamCity. We are continuing to improve the user experience for Kotlin, both in the TeamCity UI and the IDE plugin.

Once the versioned settings option is enabled for the project, we recommend making new changes in the Kotlin configuration rather than in the UI. However, it might be tempting to make the changes in the UI instead of figuring out how to define something in Kotlin. For such occasions, we have added a little UI helper to assist with the DSL definitions.

TeamCity-view-dsl

TeamCity 2018.2 introduces a new option in the UI to help anyone who uses the Kotlin DSL. You will find the new “View DSL” toggle in build configuration settings in the UI. Click the toggle to view the Kotlin DSL definition. The DSL representation opens and highlights the setting in focus.

dsl_for_blog

Check out the screencast demonstrating the new feature in action:

Posted in Blogroll, Features, Tips&Tricks | Tagged , | Leave a comment

Webinar recording and Q&A: What’s New in TeamCity 2018.2

Missed the webinar? No problem – the recording of our January 8 webinar, What’s New in TeamCity 2018.2, is now available.

In this webinar, Anton Arhipov showcases the major features of the latest release. He goes over the secondary node setup and explanation, building GitHub pull requests, showcases the simplified installation of plugins, previewing Kotlin DSL configuration in the UI, automatic assignment of investigations, and metadata in tests.

Enjoy watching and feel free to share with your friends and coworkers.

Q&A from the session

Q: Can secondary server node feature be used for migration to another server (add secondary, remove primary)?
A: Read-only (available in 2018.1 already) node can to some extent. We also plan to cover the use case when further extending the multi-node setup.

Q: The example shown for secondary nodes had both servers running on the same computer. Is this required, or can the secondary node be on a different system? And if it can be different, can it be on a different OS (Linux/Windows, etc.)?
A: They can be installed on different machines. Different OSes are also supported. It is required to share the data directory somehow (Windows SMB or Linux NFS will work). Still, it makes sense to have the same OS for both servers to simplify the setup.

Q: Does the Agent and/or Server restart when installing new plugins?
A: The server loads the plugin without restart. Since this plugin brings in an agent part, that agent part is automatically downloaded by all the agents and the agents are restarted automatically. This agent update just takes some time.

Q: When an Agent restarts, is it rebooting the machine or stopping and starting the TeamCity agent service?
A: Only the TeamCity agent service is restarted. The Agent restarts and updates without the whole machine restart.

Posted in Features, Webinar | Tagged , , , , | Leave a comment

New in TeamCity 2018.2: Metadata in Tests

Ever since TeamCity 2018.2, a test run in TeamCity can be associated with some supplementary information (metadata), in addition to a test’s status, execution time, and output. This information can be used to provide things like extra logs, screenshots, numeric values, and tags.

You can now use service messages to report this kind of additional test data in TeamCity and then view it using the TeamCity Web UI. Consult the corresponding documentation for details.

On GitHub, you can find a sample project that demonstrates the use of metadata with tests. In TeamCity, create a project from the URL using this GitHub repository, and then run the build. Once the build completes, on the Tests tab, next to the test name, you will notice a paperclip icon indicating that the test results include additional metadata.

TeamCity-test-medatada

By clicking the icon, you will open a popup displaying the attached metadata. The same information is presented on the build overview screen. Notice that a numeric value renders a 2D-graph from the historical results.

TeamCity-test-metadata-overview

In the demo project, see CodeTest.kt for the examples of the metadata reporting code.

Posted in Blogroll, Features, Tips&Tricks | 5 Comments

New in TeamCity 2018.2: Increased Scalability

TeamCity 2018.1 allows you to set up a “running builds node.” The node handles data coming in from the build agents. There’s also the “read-only node” for handling disaster recovery scenarios.

TeamCity 2018.2 expands this setup further, making it possible to delegate polling of version control systems to a secondary node.

Currently, it may seem a little complicated, but our intention is simple. We want to have a scalable architecture where you can add more nodes to the cluster so that all the nodes are uniform and can perform all the tasks in an interchangeable way. The only exception will be the main TeamCity server where we configure the cluster. Upgrade, licensing, and diagnostics are also handled by the main TeamCity server.

As a step towards this uniformity, there is no “read-only node” anymore, and it is now called a “secondary node.”

The secondary node is just a TeamCity server started with the additional nodeId argument:
TEAMCITY_SERVER_OPTS=-Dteamcity.server.nodeId=<some id> teamcity-server.bat|sh start

See our documentation on how to configure and start a secondary node.

TeamCity-Nodes

By default, the secondary node acts as a read-only node. It does not change any data, but only shows the user interface in read-only mode. This setup is well-suited for disaster recovery tasks.

Using the Nodes configuration page of the main TeamCity server, it is now possible to delegate VCS repositories polling responsibility to this secondary node. After that, the secondary server will handle all VCS polling related tasks and commit hooks. In some scenarios, this can greatly reduce the CPU load of the main TeamCity server.

Note that if there are existing commit hooks on the main server, you do not need to change anything. The main server will accept the hook and delegate its processing to the secondary node.

Right now, the secondary node cannot handle data from agents like the running builds node can. But this will change in the future versions of TeamCity. Agents’ data handling will be another responsibility for the secondary node.

Posted in Blogroll, Features | Tagged | Leave a comment

TeamCity 2018.2.1 is out

Today we’re announcing TeamCity 2018.2.1, a bug fix update for our recently released version.

This version fixes about 100 issues, most notably upgrade-related problems. Besides, LDAP authentication now works properly when a trusted certificate is added to the TeamCity server. Several important UI improvements have been made as well; the full list is available in our release notes.

We strongly recommend upgrading, as this build also addresses some TeamCity performance issues.

As usual, TeamCity 2018.2.1 update has the same data format as all 2018.2.x versions, allowing you to upgrade / downgrade easily within these builds.

Remember to check our Upgrade Notes and use one of the upgrade options:

We appreciate your feedback in our forum or tracker.

Happy holidays and happy building!

Posted in Bugfix, Release, Uncategorized | Tagged | 8 Comments

TeamCity 2018.1.5 is here

Today we’re releasing the TeamCity 2018.1.5, the last bug fix build for the previous TeamCity version.

Although TeamCity 2018.2 is already out, we’re rolling out this update as it addresses a few important issues; see all of them listed in our release notes.

As any TeamCity update, 2018.1.5 has the same data format as all 2018.1.x versions, allowing you to upgrade / downgrade within these builds easily.

Remember to check our Upgrade Notes and use one of the upgrade options:

We’ll appreciate your feedback in our forum or tracker.

Happy building!

Posted in Bugfix, Release | Leave a comment

Webinar: What’s New in TeamCity 2018.2

Join us January 8, 2019, 5:00 PM – 6:00 PM CET (11:00 AM – 12:00 PM EDT) for our free live webinar, What’s New in TeamCity 2018.2.

c

In this webinar, Anton Arhipov will go over the new major features of the latest TeamCity 2018.2. You will see:

  • How to set up a secondary node for collecting changes from VCS.
  • What TeamCity now offers for working with GitHub pull requests.
  • How installing and updating plugins from the plugin repository has been simplified.
  • Why adding screenshots and other data to test results can provide more insight.
  • How previewing Kotlin DSL code for project and build configuration settings can simplify adopting the configuration as code paradigm.
  • How automatic investigation assignments help notify the right team members of a build failure.
  • When you should enforce build steps and requirements in templates.

Space is limited, so please register now. There will be an opportunity to ask questions during the webinar.

Register for the webinar

Anton ArhipovAnton Arhipov is a Developer Advocate for JetBrains TeamCity. His professional interests include everything Java, but also other programming languages, middleware, and developer tooling. A Java Champion since 2014, Anton is also a co-organizer of DevClub.eu, a local developer community in Tallinn, Estonia.
Posted in Features, Webinar | Tagged | Leave a comment