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 the 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
- as your project source code
- , you can now start remote run/pre-tested commit with changes made in the
.teamcitydirectory, and these changes will affect the build behavior
- if you are using TeamCity feature branches, you can define a branch specification in the VCS root used for versioned settings, and TeamCity will run a build in a branch using settings from this branch
- if you're starting a history build, TeamCity will try
- to use the settings corresponding to the moment of the selected change.
Note: 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 the build configuration
- changes in agent requirements, build failure conditions and build
- features 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.