On this page:
Bundled .NET CLI plugin
With this EAP build we bundled one of the highly popular TeamCity plugins: .NET Core. The plugin name has been changed to .NET CLI and the plugin itself has been significantly reworked and improved in terms of functionality and usability.
The plugin is intended to simulate the behavior of the dotnet command, which is fully supported out of the box now with the following additional features:
- automatic discovery of build steps when given the URL of your repository
- detection of .NET CLI on the build agents
- hierarchical build log
- real-time reporting of tests, compilation errors or other problems
- code coverage powered by JetBrains dotCover
Deployment type for build configuration
Up until now, except for a set of runners for deployment tasks, there were no other dedicated deployment-related features in TeamCity.
In this EAP we introduce one more type of build configuration: Deployment. Now you can mark build configurations, performing deploying of artifacts of other builds to some environment, with this type. Once a configuration is marked as Deployment, TeamCity changes behavior in the following way:
- The Run button caption for this configuration changes to Deploy
- TeamCity automatically disables the ability to run personal builds in this configuration and also limits the number of simultaneously running builds to 1
- If there is a build used as a dependency in a Deployment configuration, then the Deployments section will be shown on the build results page of this build, allowing to quickly deploy the build
- The Change status page (the page where you can see which configurations are affected by the change, and which builds have been executed with this change) has got a Deployments tab that shows builds in Deployment configurations where this change was deployed for the first time
- Usually TeamCity shows the build with the latest changes for a given build configuration on the project overview or dashboard pages. It means that a build started on a non-latest change (the so-called History build) is not shown on Overview by default. But for Deployment configurations TeamCity always shows the latest started build, regardless of the changes it contains.
Composite builds feature has got additional improvements in this EAP:
- Artifact dependencies in composite builds now support include and exclude rules, as well as mapping of files to different directories
- If the dependencies of a composite build publish code coverage or results of code inspection / code duplicates analysis, then the composite build will show published statistics data from these builds on its build results page
REST API based pages
In this EAP we unveil a set of pages which use components built with React and serve data provided by the TeamCity REST API. In the future versions we plan to use this approach more and more often.
All Finished Builds page
The All Finished Builds page allows server administrators view and filter finished builds. By default the builds can be filtered by build status: Successful, Failed, Canceled and Failed to start, as well as by project or build configuration. Since the results are obtained via the TeamCity REST API, all build locators are supported by the advanced search options.
This page is especially useful right after the upgrade of the server. With help of this page system administrators can find recently failed builds faster, which in turn helps to identify compatibility problems which can occur right after the server upgrade.
New look for Agents page
The Agents page is also built using the data provided by the TeamCity REST API and boasts a new, fresh look. The page is optimized to work just fine with hundreds of agents and not to load the browser CPU.
Besides agent history page has been reworked too and it now looks like All Finished builds page.
Kotlin DSL improvements
Two major improvements have been done to Kotlin DSL:
- ability to use external libraries
- dedicated DSL now is available for a number of plugins, like Docker, .NET CLI, Coverage or Commit status publisher
If you want to use an external library in your Kotlin DSL code, simply add a dependency on this library into the pom.xml file. In this case, before starting the generation process TeamCity server will fetch necessary dependencies from Maven repository, compile code with them, and then start settings generator. So if you ever wondered how to share code between different Kotlin DSL based projects - now it became possible.
Dedicated DSL for Docker, .NET CLI, Code coverage plugins and others
The dedicated DSL code is now provided for a set of new plugins bundled with TeamCity. Below you can find some examples:
The typical DSL code for the Docker-Compose build step:
MSBuild with JetBrains DotCover:
Java code coverage:
Bundled tools updates
- Tomcat has been updated to version 8.5.23
- The bundled .net Tools, dotCover, and ReSharper Command Line Tools have been updated to the latest released version, 2017.2.2
- The bundled JRE updated to 1.8u151
- Commit Status Publisher supports VSTS/TFS pull request statuses
- This builds features a number of Perforce-related fixes (TW-47300, TW-48038, TW-49858)
- Administration pages now boast of the new sidebar, which improves visibility and usability
- Builds on the Changes page now show a progress bar
- The “Show projects hierarchy” checkbox has been added to a number of places where a list of builds is shown: snapshot dependencies, changes page, change details page. If the number of builds is large, projects hierarchy can help to find the relevant build faster
- Test history page has been cleaned up / reworked a bit
- All fixed issues