Build Sequence Improvements
Propagating build failure status through dependencies
Now a build that depends on a failed build will always fail with appropriate text in the build status.
Run build if one of its dependencies failed
An option to run the build or just skip it if any of its dependencies has failed has been added.
For example, you may have two different build configurations, in particular, the first one is intended for compiling your code, the second - for running tests of the first build results'. If the compilation has failed, you will most likely want to skip running tests and save the time. Alternatively, if a build performs some post-build action such as publishing build results on some resource, it should be run after both failed and successful builds.
Configurable build reuse policy
Now you can configure whether to use the already finished/running builds as a source of the build dependencies, or trigger a new build each time a build with dependencies is triggered. The build can be reused in dependencies only if it is suitable for replacement (i.e. it used the necessary revisions and had no custom parameters set).
There is also an option to limit builds reusing only to successful builds.
In the Run Custom Build dialog you can now opt to trigger a build enforcing rebuild of all its dependencies.
Option to preserve dependency builds from cleanup
We have also added an option in cleanup rules to turn off preserving dependency builds from cleanup. Now for each build configuration you can configure whether you want to preserve or not the artifacts of the builds that this configuration depends on.
History builds with source dependencies
It is now possible to trigger a history build for builds with source dependencies.
Ability to stop multiple builds from the same dependency graph
When stopping a build or removing a build from the queue, a dialog with a list of all builds of the same dependency graph (as the one being stopped) opens. You can then select the builds that you want to stop.
Patterns of artifacts now support Ant-like wildcards.
In artifact dependencies you can now specify individual files from zip-archived artifact in the dependency rules. The complete archive will be downloaded to the agent, but only the specified files will be put into the destination directory.
Now you can select remote run comment from the history of previously entered comments.
Also, a notification on the personal build failure is now displayed.
Version Control Integration Improvements
- can now label the build's sources even if custom client mapping is specified in the VCS configuration.
- excludes in custom client mapping are now supported.
- Subversion 1.5 externals format is now supported.
- bugfixing and speedup
- now quiet period is more fair, i.e. if there were no changes within the specified quiet period a build is added to the queue for the last detected change and when the build is started no changes collecting is performed.
We have opened sources of ClearCase VCS integration and Eclipse TeamCity plugin. We use the repository as our primary storage for the plugins sources and all our current work is done in the repository. The sources correspond to our current state of the sources (that we release as EAP builds).
If you feel like investigating the sources and can propose a patch, go ahead! Let us know what you think in the TeamCity plugins forum.
- Ability to add a comment to a build.
- Ability to trigger a build on all compatible agents: see the last option of the Agent drop-down list of the Run Custom Build dialog.
- Search by build and pin comments, change set and file revisions is now turned on by default.
- Project copying improvements: now the project-related notifications for all users are also copied.
- Duration sub-total is shown for filtered tests on the Tests tab.