Hi everyone!
We’re already counting the days till the final TeamCity 7.1 release, and today we have a fresh new EAP build for you which is basically what the release build is going to be like, except we still need to polish a few things. So we encourage you to try it, and help us improve it!
Check out the release notes, which is all about bug-fixes now, try the build out and send us some feedback!
Stay tuned, we’re almost there!
The release of TeamCity 7.1 is so far planned for mid-June, and today we launch the early access program, so don’t sit on your hands – grab the first EAP build while it’s hot! Today’s menu includes:
If you need to monitor problems in many build configurations, you can now get the whole picture right on the overview page without having to expand each and every build configuration in question:
Normally an investigation assigned for a build configuration or a test is automatically cleared once the build configuration becomes green or the test passes. What if it’s a “flickering” test: green-red-green-red… and so on? Still has to be investigated! To allow better management of such problems we introduced manual mode for investigation resolving. When you assign an investigation you can select how you want it to be resolved: automatically, or manually:
In several places in build step settings, where a path to a build script can be specified, a small icon appeared: 
. By clicking on this icon you’ll be presented with a VCS repository browser allowing you to choose a file in repository.
Find the details in the complete release notes, try the build and share your feedback with us!
Enjoy!
Today’s TeamCity 7.0 EAP is the last EAP build with new features in it, as starting from it we are going to focus on fixing bugs and polishing already announced functionality. So basically, this build is more or less what TeamCity 7.0 is going to look like. So here’s what we have for you today.
A feature request to allow build configuration editing via REST, that has been around for a while, has finally been implemented, so now you can get complete settings of a build configuration or template via REST and change them as well. Moreover, you can create and delete build configurations, projects and VCS roots.
See the details in release notes.
We would appreciate if you could try the updated REST API and let us know about any issues or suggestions that you might have.
If you have been following the EAP program you’re probably already familiar with the new Dependencies graph that shows all build chains of a particular configuration or a build.
However, with this EAP build you will have much more control over your build chains, for example start dependent parts of the chain using the same revision for dependent builds.
The whole thing is similar to a “pipeline”, at any stage of your release process you can easily prolong pipeline to some further stage.
TeamCity now uses Java based back-end for handling NuGet feeds. This should simplify setup of NuGet in TeamCity and as an additional benefit you can use TeamCity NuGet feed feature if server is installed on Unix.
Both Maven2 and Maven3 are now bundled with TeamCity. You can choose required version of Maven on the Maven runner page.
Additionally you can instruct Maven runner to use unique local artifacts repository for the builds of build configuration.
See the complete release notes, back up your TeamCity instance, try the build and share your feedback with us!
We’re going to try to publish bug-fix builds more often than regular EAP builds, preferably once in two weeks, so stay tuned!
Right in between Christmas and New Year’s eve we’ve got a shiny surprise for you – new EAP build. It’s going to be hard not to notice the changes in today’s TeamCity EAP build, because we’ve significantly changed user interface aiming to make it more friendly, logical, simple and clear. To begin with, we have redesigned the Administration page to provide faster and easier access to frequently used sections and simplify navigation by grouping settings.
Secondly, it is now very easy to see when a test failed for the first time: you can find this information right above expanded stacktrace:
We decided to get rid of Bulk mode and always show check boxes near test names instead.
In addition to mentioned changes, there are numerous usability improvements: the whole list you can find in the release notes.
However, changed look is not the only noteworthy thing here. In one of the previous EAP builds you could have noticed an experimental feature “Types for build properties”. Since then, it has been greatly improved and now it’s ready to use! The following types are now supported:
Note, that if you want to use a typed parameter to introduce a password field in Run custom build dialog, values of password parameters will be hidden from build log and Build Parameters tab of the build, plus values of these parameters can’t be seen in custom build dialog and are stored in scrambled form in configuration files.
As usual, these are only the highlights and there are more to it, so we recommend to take a look at the release notes and give it a try!
Happy New Year and happy building!
Today we’re making available yet another TeamCity 7.0 EAP build with lots of cool stuff in it. As usual, you can get a taste of features that are going to be in version 7.0 even before it is released. So if you’re wondering, what is there – here’s a list of things you couldn’t do before, but can try out now:
Previously, there was no specific place where you could see all investigations assigned to you. Of course you had notifications, and you could see this information in each particular build configuration, but it would be much more convenient to have a dedicated page for that – who knows how many projects and build configurations are affected by your changes and in how many of those you are supposed to investigate failures. Now it’s easy to take a glance at the whole picture – just click a little box with a number next to your name.
It is now super easy to browse inside artifact archives right from the TeamCity web interface!
Moreover, you can download some particular file from an archive using new URL syntax:
http://<server url>/repository/download/<build conf id>/<build>/<archive>\!<path in archive>
Plus it made easier configuring Report Tabs.
Since we have introduced build steps, one of the most awaited features was an ability, to temporary or permanently disable some setting in build configuration. For example, if you have a configuration inherited from a template. Now you got it! Even better, you can not only enable/disable build steps, but also build triggers, build features and build failure conditions!
TeamCity now can act as NuGet server serving NuGet packages published to TeamCity as regular build artifacts. When a build publishes NuGet package as artifact it is automatically added to TeamCity NuGet feed. This feature needs to be enabled explicitly on Administration -> Server Configuration -> NuGet tab.
Note, current implementation of NuGet shows all found packages within TeamCity installation. Access rights are only checked on downloading packages bits. There is a related issue for it though: TW-19157.
Of course, we also greatly improved features introduced in earlier EAP builds.
Don’t forget to back up your TeamCity instance, try the build and help us make another one better for you!
Enjoy!
“I see dead code” – .NET developers all over the world know this slogan due to incredible code analysis feature provided by JetBrains ReSharper. One of the most wanted TeamCity features was to have .NET inspections results right on build server. Starting with the latest EAP you have it!
The only thing you need to do to get all the benefits of ReSharper’s analysis right in TeamCity is to add Inspections (.NET) build runner as a build step to your build configuration.
Configuration is quite easy, so let’s just take a look at how the results look when this runner is configured – you can find them at the dedicated “Code Inspections” tab of the build results.
Here we’ve got all the usuall options like exploring overal inspections statistic, opening problematic sources in IDE, viewing inspections description, etc.
Moreover, using this build runner together with another fresh feature – build failure conditions, you can update your builds status based on of inspections results.
What’s next? First of all, in the nearest future it will be possible to share ReSharper inspections settings profile between your team members and use this profile in TeamCity build. More to come, you will be able to ask TeamCity to run custom inspections related to your code base as well.
As always, your comments and feedback are very much welcome. To try it, install TeamCity 7.0 EAP build.
Enjoy!
New TeamCity 7.0 EAP build is ready and waiting for you to try! We have improved features introduced in the first EAP build, and of course we’ve got some completely new stuff.
Yes, it’s finally here and it’s based on powerful ReSharper code analysis engine! Now you can run .NET inspections and see the results right in TeamCity.
Previously you could specify path to alternative user settings file (equivalent to Maven command line option -s or –settings) in build configuration. Now you can define these settings xml files globally in Server Configuration area, and use them in your Maven builds. When you create or modify a build configuration you will only need to select, whether you want to use default settings file (chosen by Maven), specified by path or global (uploaded on server). Since TeamCity stores these files under <TeamCity Data Directory>/config/_mavenSettings , you can update them there whenever you need.
If you have fast builds, you can now trigger them for each check-in, or for a group of check-ins made by the same user. Why? Thus you will see right away who broke what! When a build contains one check-in, or a couple of check-ins by one user, there can be no doubts, who’s responsible for a new failed test. ;)
We’ve already mentioned this feature in one of the recent posts, though we have improved it since then and we would like to hear your feedback on it.
If your project uses Git or Mercurial you can see graph of commits on build configuration change log page. Graphs are also useful for non-DAG-based VCSs: they make it easier to understand where a VCS root modification comes from.
We’ve improved, reworked and made better:
Don’t forget to back up your TeamCity instance, try the build and help us make another one better for you!
Happy building!
Previously described Fail build on metric change feature is not the only new way of controlling build status and detecting build failures. In TeamCity 7.0 we introduce one more useful feature that allows to mark build as failed, in case when certain line is met in build log.
Note, that you can instruct TeamCity to look for a line containing or matching a Java Regular Expression regexp text that appears/doesn’t appear during the build. When the condition is set, the interface looks like:
Here’s how a build failure looks when caused by such condition:
The feature is not completed yet, so your comments and feedback are very much welcome. To try it live, install TeamCity 7.0 EAP build, we recommend the next EAP build which is about to be released in the nearest future.
Enjoy!
As the major TeamCity 6.0 release approaches, the release candidate build is already available. Besides bug-fixes, it contains several enhancements and improvements. For example:
As usual, we remind you to back up your data before upgrading to a new version. Stay tuned, the big day’s closer than it might seem;)
Download TeamCity 6.0 RC.
New TeamCity 6.0 EAP build is now available with Gradle support described in previous post and several new features and major improvements:
See the release notes for complete list of changes, download the build and send us your feedback!
And as usual, don’t forget to back up your data!;)
Twitts about TeamCity