Improved Versioned Settings
We've made some major refactorings to allow TeamCity start builds in a build configuration with different settings. For instance, internally it is possible to start a build with build steps, build features or parameters completely different from those defined in build configuration. This redesign allowed us to add some new interesting possibilities for projects where versioned settings are enabled:
- if you keep TeamCity configuration files in the same VCS root where your project source code resides, you can now start remote run/pre-tested commit with changes made in
.teamcitydirectory, and these changes will affect build behavior
- if you are using TeamCity feature branches, you can define branch specification in VCS root used for versioned settings, and TeamCity will run a build in branch using settings from this branch
- if you're starting a history build, TeamCity will try using settings corresponding to the moment of the selected change
Before starting a build, TeamCity stores configuration for this build in build internal artifacts under
.teamcity/settings directory. These configuration files can be examined later to understand what settings were actually used by the build.
Currently there are some limitations which we hope to overcome in the future:
- changes in snapshot dependencies will be ignored, TeamCity will continue reading snapshot dependencies settings from build configuration
- changes in agent requirements, build failure conditions and build feature working on the server (like automatic merge and labeling) are ignored too
- changing of some of the settings does not make much sense for build, for instance, build triggers, general settings like limitation on a number of concurrently running builds, and some others
Support for NUnit 3.0
Starting from this EAP, the TeamCity NUnit runner supports NUnit 3.0.
We'd like to thank NUnit team who kindly accepted our patches adding TeamCity service messages support into NUnit itself. Now, starting with NUnit 3.0.0 Beta 2, NUnit detects if it is run by a TeamCity build agent and automatically switches to reporting test runs using TeamCity service messages.
File Content Replacer
TeamCity already has a build feature, allowing you to update the
AssemblyInformationalVersion attributes in
AssemblyInfo files of a solution.
In this EAP build we added a more general build feature, File Content Replacer, enabling you to change a wider range of values for the duration of the build in files specified by the user. It provides value pre-sets for replacement; custom values can also be used. On build finishing, the changed source files are reverted.
Multiple Artifact Directories Paths
By default, TeamCity stores build artifacts in
<TeamCity data directory>/system/artifacts. Starting form this EAP, it is possible not only to configure the artifact path, but also to use multiple paths: the new-line delimited list of paths to artifact directories can be specified on the server Administration | Global Settings page. Absolute and relative paths are supported; the relative paths are relative to TeamCity Data Directory.
If a new build starts, its artifacts are published into the first directory in the list. When looking for artifacts of earlier builds, TeamCity will go through the list of the artifact directories to locate the directory where build artifacts are stored.
Restricting Remote Run in Builds
Using a new build option in the General settings of a build configuration, you can restrict running personal builds. By default, triggering personal builds is enabled; uncheck the allow triggering personal builds option to disable it.
ANSI-style coloring in build logs
TeamCity build logs now support 16 basic ANSI color escape sequences and render clickable hyperlinks:
- The bundled Ant has been updated to 1.9.5. Ant-runner build steps require Java 1.5 at least.
- The bundled Java has been updated to version 8.
- PowerShell 5 is now supported
- The TeamCity Web UI now allows specifying custom commandline parameters to pass to dotCover.
- TeamCity REST API adds more abilities to filter builds for the
/app/buildsrequest. For example, now it allows retrieving entire build chains with a single request.
- fixed issues