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.
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
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
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:
See the structured list of dependencies.
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 requestsIn 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:
- 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