Child pages
  • Kanpur 2019.2 EAP3 (build 71010) Release Notes
Skip to end of metadata
Go to start of metadata

 

On this page:

Running personal builds on unified diffs

Now you can run a personal build containing your local changes based on a diff patch uploaded via the TeamCity UI or via REST API.

Previously, it was possible to run personal builds, based on your local changes, only by integrating your TeamCity server with some supported IDE. Since this EAP, you can simply save your patch as a .diff file in a unified format (for example, using IntelliJ IDEA or the git diff command) and upload it directly to the server.

To upload a patch via the TeamCity UI, open the Run Custom Build window and turn on the run as a personal build option to enable the Upload patch button.

Upload the patch and click Run Build. The agent will receive the patch and apply it before running the build. After the build, it will revert the patch so the checkout directory can be reused by subsequent builds.

To upload the patch.diff file to the server via REST API, follow the instructions described in this issue.

Note that this is an experimental feature. TeamCity provides a stable parsing of unidiff files generated by Git and IntelliJ IDEA. Binary changes in non-binary files are not supported.

Pipeline DSL

Pipeline DSL is an alternative way of representing a build chain structure via TeamCity Kotlin DSL.

This implementation is a work in progress: we aim at making the pipeline notion more descriptive and extending its functionality. The described syntax might be changed in the released version of TeamCity. To be able to use the current pipeline DSL syntax, users will have to import the v2019_2_eap package, as described below.

Pipelines are defined inside the project specification in the settings.kts file. A pipeline consists of nested blocks, specified either as a sequence (method sequence()) or in parallel (method parallel()) to each other. These blocks represent build configurations (method buildType()) interconnected via implicitly defined dependencies.

When composing a pipeline, you can use already specified build configurations, or declare new ones via inline buildType() definitions. TeamCity will create all declared build configurations in the current project, if they do not already exist in it or its subprojects, and add all the specified dependencies between them.

The following example illustrates a typical pipeline for compiling and deploying an application.

Explicit snapshot dependencies can be also defined via a dependsOn() statement within any block (that is parallel, sequence, or buildType), with an optional lambda argument that allows setting dependency options. The options for implicit snapshot dependencies should be defined via an optional dependencySettings lambda argument of any block, while artifact dependency options should be defined within an optional lambda argument of consumes() call.

Redesigned Build Page in experimental UI

In this EAP, we are introducing a new user interface for the Build Details page.

The page will be available if the new UI is enabled on the server in My Settings & Tools. You can switch to the new representation from the classic UI by clicking in the upper right corner of the page.

In our attempt to rethink the approach to displaying build details, we have redesigned the Build Page so it provides better visualization and gives quick access to all other projects via the sidebar.

Note that this implementation is a work in progress: it can be changed significantly in the released version of TeamCity. We would be glad to hear what features and ideas you like and what changes seem inconvenient. Any feedback is welcomed.

Most notable features are:

  • Instant view of the previous builds

Hover over a build on the graph to see its details.

  • Visualized build timeline

Identify build stages where the problems occurred.

  • Reworked build log

  • Real-time snapshot dependencies chart

  • Different views for build dependencies

Choose a view that is most convenient for your current task, including:

 List view

See the structured list of dependencies.

Timeline view

View a timeline of dependencies: how long each dependency build was in the queue, when it started, what other dependencies preceded it, and so on.

 

New settings of retry build trigger

The retry build trigger automatically attempts to rerun a failed build until it becomes successful. We have added three additional settings for this trigger:

  • Trigger a new build with the same revisions
    With this option enabled, the retry trigger will rerun a failed build using the same source revisions. This helps identify build problems that do not depend on the build code: for example, if there are flaky tests in the build configuration or if there was some unforeseen agent compatibility issue.
    If the build with the trigger is a part of a build chain, all the successful builds from the previous chain run will be reused and all the failed dependency builds, that could have contributed to the failure of the dependent build, will be rebuilt on the same revision.
    All parameters and comments specified in the custom build settings will be applied to the following build runs initiated by the retry trigger.
  • Put the newly triggered builds to the queue top
    With this option enabled, retried builds will always be put to the queue top.

  • Branch filter
    You can now apply a branch filter to rerun failed builds only in branches that match the specified criteria.

Predefined build parameters for pull requests

In this EAP, we have added a few predefined build parameters to expose valuable information on pull requests, so it can be used in the settings of a build configuration or in build scripts:

Other improvements

  • You can now enforce the interval of VCS changes check, specified in Global Settings, as a minimum polling interval for all VCS roots on the server. This way, Project Administrators will only be able to set intervals that are larger than the default one. This helps restrict the frequency of polling requests thus offloading the server.
  • You can now apply a branch filter to an artifact dependency. It allows using artifacts from the latest build from any matching branch or all branches.
  • The Docker client in the TeamCity Linux agent image has been upgraded to version 19.03.3 to prevent the problems with unexpected Docker stop (see the related Docker issue).
  • Bundled .NET Tools (dotCover and ReSharper CLT) have been upgraded to version 2019.2.3.
  • All fixed issues
  • No labels