"Cannot start" build errors
Sometimes a build may occur completely broken, i.e. it can't start at all. In most cases, this is caused by some configuration error. For example, VCS repository can be down when build starts, or artifact dependencies can't be resolved, and so on.
Starting with this EAP, TeamCity handles these builds more carefully. In case such error occurs, TeamCity:
- doesn't send build failed notification (unless you have subscribed to "the build fails to start" notification)
- doesn't associate pending changes with this build, i.e. the changes will remain pending, because they were not actually tested
- doesn't show such build as the last finished build on the overview page
- such builds will not affect build configuration status and status of developer changes
- shows "configuration error" stripe for build configuration with such a build
In brief, "failed to start build" is treated as a Cancelled build. However, they are shown slightly differently in the web UI:
Here, the build with red exclamation icon () is the "failed to start build".
If you are system administrator, you might want to receive notifications for such builds. For this purpose use "The build fails to start" notification option.
New IntelliJ IDEA project runner
Another implementation of the runner for IntelliJ IDEA projects is added (based on JPS, see http://youtrack.jetbrains.net/issue/TW-7084). Currently it supports compilation and artifacts building only. We will add ability to run tests in the next EAP builds. After that existing IPR runner will be marked deprecated.
Perforce agent-side checkout
Finally, we've added the long awaited feature: checkout on agent for Perforce vcs (http://youtrack.jetbrains.net/issue/TW-2103). For this feature to work, Perforce client must be installed on the agents and path to p4 executable must be added to the PATH environment variable.
ClearCase agent-side checkout
As with Perforce, ClearCase checkout on agent requires ClearCase client (cleartool) to be installed on agents and properly configured. It means that the tool must be in system paths and should have access to the ClearCase Registry.
Such checkout uses own-created ClearCase Snapshot view for changes collecting. The view is created with ConfigSpecs which are equal to ConfigSpecs of a ClearCase View specified for TeamCity VCS root.
Visual Studio Add-In Improvements
In VS Add-In you can apply changes sent in Remote Run or Pre-tested commit to the working directory. This is useful if your Remote Run failed on the server and failure can be easily fixed, but you can't fix it in the current sources because they were already changed (you continued code refactoring after the Remote Run).
Now you can shelve your changes using VCS built-in abilities (TFS or Perforce shelves for example), then apply Remote Run changes, make necessary fixes and commit, or start another Remote Run.
Swabra plugin bundled
Swabra plugin is available since TeamCity 4.5.x and now we decided to bundle it with TeamCity. The plugin purpose is to provide clean checkout directory, i.e. to remove all of the files created during the build. There is also so called "strict mode", in this case plugin ensures that no files were modified during the build, and if so, clean checkout is performed.
New version of the plugin can be configured to watch (or do not watch) for files in specific directories.
And finally, Swabra is able to report if there are stale processes, left after the build, locking the files in the checkout directory.
There were a lot of requests for build priorities feature (http://youtrack.jetbrains.net/issue/TW-5279). The fact that this feature can be implemented in a lot of different ways caused us some headache. With this EAP we've added one of the possible implementations and we are looking for your feedback. Please do not hesitate to share it with us!
Currently you can define different priority classes (this page is available from Build queue page and can be accessed by users with System administrator role only):
Then you can associate build configurations with them. Each class has a priority which can be defined in the range -100..100. The lower the range, the less priority this class will have.
Priority is only considered when build is added to the queue. The higher the priority of the priority class is, the more chances there are the build will be added at the top of the queue. Since builds with low priority should start too, one of the parameters affecting position of the newly added build, is the "time spent in the queue" of other builds. If some build has been waiting in the queue long enough, it won't be outrun even by a build with higher priority.
Note that there are built-in priority classes, which can't be removed. They have some "special" properties. For example, "Personal" class is used for personal builds (Remote run or Pre-tested commit) only, i.e. any personal build added to the queue will be assigned to this priority class.
There is also "Default" class. All of the builds not associated with any other class will be assigned to "Default" class. This allows to create a class with priority lower than default, i.e some low priority builds are always placed at the bottom of the queue.
Since build priorities are implemented as a plugin for TeamCity, we have plans to make this plugin available for TeamCity 5.1.x too. Stay tuned!
We added artifacts browser icon () in the add/edit artifact dependency dialog and in the add/edit project report tab dialog. By clicking on this icon, TeamCity will try to locate artifacts according to specified settings and show artifacts tree. The path of the file selected in the tree will be placed into the input field.
Also we've fixed performance of the artifacts browser on large trees of files.
VCS trigger rules for commit message
Now you can disable VCS triggering for the changes with specific commit messages. Read more on trigger rules syntax in TeamCity documentation.
Change log filtering by file path
If you are looking for commits which modified specific files, you can use new feature of the Change log filter (available for both project and build configuration change logs). You can specify path or a part of the path in the filter and find all of the commits affecting files with these paths.
- Administration -> Server Configuration -> Server Logs page slightly improved