TeamCity 7.1 EAP (build 23732)
Hi everyone!
Today we have a new TeamCity EAP build for you, and right now there are just a few weeks left till the official release, so this build is basically almost “the one”, except that “the one” will be more polished. So if you’re eager to be the first one to put your hands on TeamCity 7.1, this build is just for you. Let’s see what’s in it!
Feature Branches
If you have been following our EAP program, you probably noticed some sprouts of this feature, but now it has grown and expanded and you can already harvest lots of goodies out of it!
First of all, now you can configure what branches you want to monitor in a build configurations right in the VCS root (Git and Mercurial only), just use syntax similar to checkout rules:
Use * to list the branches. For example, +:refs/heads/* will match refs/heads/feature1 branch, and in TeamCity interface you’ll see feature1 only as a branch name.
Once you’ve specified the branches, TeamCity will start to monitor them for changes, and if you have VCS trigger and a change is found in some branch, TeamCity will trigger a build in this branch.
You’ll also be able to filter history, change log, pending changes and issue log by branch name. Also branch names will appear in custom build dialog, so you’ll be able to manually trigger a custom build on a branch too.
But that is just a tip of an iceberg! There’s more to it! This feature affects many aspects of TeamCity behavior: for the details please refer to the release notes.
Other Improvements
Unified look for Change Log, Pending and build Changes pages
We have reworked Pending and build Changes views to look similar to Changelog, for instance, you’ll find graph of commits on the build Changes page as well. You can also notice a new option “Show files” which allows to easily expand all changes on the current page and show affected files.
Manually changing build status
Sometimes you may need to mark a failed build as successful, for example, if a failure happened because of a minor problem, and you want other builds to take artifacts of this build, or your want to promote this build further by pipeline. On the other hand, there are cases when TeamCity was not able to determine build failure. For example, build finished successfully but because of an error in build script it did not produce any artifacts. So the build clearly cannot be treated as successful. Now you can change the build status manually, provided you have enough permissions to do that.
Build Steps Execution
Build step execution policies introduced in the previous EAP have been improved. We’ve added “Always, even if build stop command was issued” option to “Execute step if” drop-down which can be useful for some cleanup tasks. Note that as in previous TeamCity version whether the step is failed or not in most of the cases is determined by process exit code.
NuGet Support Improvements
- We added support of NuGet 1.8/2.0. Now you may even upload your own NuGet.CommandLine package instead of downloading it from the public feed.
- NuGet Trigger now supports Prerelease packages.
- We improved NuGet Installer runner. It no longer requires you to have
packages/repository.configfile under solution. Starting from this release, NuGet Installer uses Visual Studio solution file (.sln) to create the full list of NuGet packages to install. It also supports Solution-Wide packages, from.NuGet/packages.configfile. We added an option on how packages upgrade is done. Now you may select to update packages for entire solution of perpackages.configfiles.
See the complete release notes, back up your TeamCity instance, try the build and share your feedback with us!
Stay tuned!
Subscribe to TeamCity Blog updates
