Today we publish yet another bug-fix EAP build. In addition to a number of fixed issues (see the whole list), this build adds an ability to change project level parameters by means of REST API. See the release notes.
Download and try it!
Looking forward to your feedback!
The closer we get to the finial TeamCity 7.0 release date, which by the way is a matter of few weeks, the more we need your feedback on the EAP builds. So we decided to publish them more often than we usually do. Today’s build comes with a number of improvements and bug-fixes that mostly address REST API, user interface and build triggers. See the release notes.
We have also added support for Subversion 1.7 for both checkout on server and checkout on agent, and introduced new permission “View user profile” that restricts/allows access to user email and settings.
We encourage you to try the latest EAP build and give us more feedback.
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!
Look out world, we have just opened early access program for the next TeamCity version: code name Faradi. That means you can download the first TeamCity 7.0 build right away and try all the cool features that are in it. Want to know what features are there? Here’s a list:
TeamCity has become smarter in deciding when a build is to be considered “failed” – now it can look beyond the obvious like exit code or failed tests presence. Basically, you can instruct TeamCity to mark a build as failed if it has become “worse”. There is a number of metrics in TeamCity already to measure how “good” a build is, like code coverage, or artifacts size, etc., so all you need now is set up the threshold for those metrics that are important to you. For instance, you can mark build as failed if code coverage or code duplicates number is worse than in the previous build. Learn more about this feature from the related post. However, that’s not the end of the story. Another build failure condition is on its way – it’ll allow to mark build as fail when a certain message is met in build log. This functionality is still quite raw though.
By the way, don’t panic when you don’t find good old “Fail build if” conditions that used to be at the General Settings page – we didn’t drop them, just moved to the new page with the rest.
Starting with TeamCity 7.0 it’s easier to organize your build agents and calculate the required agents capacity. Instead of having a a single set of agents, you can now break it into smaller groups called agent pools. In two words, a pool is a subset of agents to which you can assign projects. Thus you can run your project on a subset of agents and make sure no other projects will run in the same pool.
Maven, Gradle and IntelliJ IDEA Project build runners now support dependency based run of tests. One of the best practices in software design is to make modules as independent as possible, and if you follow this practice, now you can get an extra bonus – faster builds in TeamCity, because TeamCity can run only those tests that are really affected by changes in dependencies.
Learn more in the release notes.
TeamCity now comes with native NuGet support. The plugin that provides NuGet support has become available a couple of weeks ago, and now it is bundled with TeamCity. There was a series of blog posts dedicated to this plugin, so we won’t go into details here:
As a side note, the plugin is compatible with TeamCity 6.5, so if you want to use it in your existing production server, you can download it at teamcity.jetbrains.com.
… including build performance monitor, improved My Changes page and Build Log, support for Subversion 1.7 in Visual Studio Addin, and so on. See the complete release notes, try the build and share your feedback with us!
Don’t forget to back up your TeamCity instance, and note that starting with this version TeamCity server and agent require Java 6.0 or later.
Stay tuned, we’ve just got the ball rolling!
One of TeamCity’s remarkable features is a possibility to analyze the code of your application, find duplicates, show corresponding reports and charts. You can calculate code coverage metrics, run code inspections, and see results right in the TeamCity’s UI. And in most cases, these features work out of the box, without setting up additional external plugins.
All these code examining tools generate various numeric metrics, and you can see the dynamic of their change in the TeamCity UI.
What you could not do before (well, almost could not) is to specify metric thresholds, which would fail the build upon exceeding them. For instance, you couldn’t tell TeamCity that the build must fail if code coverage or code duplicates number is worse than in the previous build.
Corresponding requests stayed for a while in our tracker and collected quite a few number of votes:
- TW-2539 Inspection Build: fail if more inspection errors than in last successful build
- TW-3040 Make build fail if code coverage is below certain threshold
- TW-3041 Make build fail if code coverage is below previous code coverage value
- TW-4953 Setting to fail a build when number of found code duplicates exceeds some threshold
- TW-15679 Option to fail a build if a specific statistics value is below/greater then in last successful/tagged build
When we started pondering over the task, it became obvious, that it can be generalized. And besides code quality, we could consider other metrics, such as number of tests in a build or volume of published artifacts:
- TW-12449 Option to fail a build if test number drops
- TW-5451 Option to fail a build when not all artifacts are published (artifacts validation)
Moreover, if a build publishes its own numeric metric (and it is very easy to set up), this metric can also be used to determine build status.
So now you can specify several metric-based build failure rules for a build configuration:
As you see, you can create rules for both the absolute metric values, and for the difference with a previous build in the same build configuration. As a previous build anchor, you can use:
- last finished build
- last successful build
- last pinned build
- build with a specified build number
- last finished build with given tag
The default list of available metrics is:
- artifact bytes (you can fail a build, if not all artifacts were published, basing on their volume)
- number of tests in a build
- number of ignored tests
- code inspections: errors, warnings
- code duplicates count
- code coverage percentage – lines, blocks, methods, classes
To add your custom metric to this list, you have to change TeamCity’s configuration file main-config.xml (<TeamCity data directory>/config/main-config.xml) and add the following section there:
<build-metrics>
<statisticValue key="my_file_count" description="number of files"/>
</build-metrics>
So, if your build will publish value my_file_count, you can use it as a criteria for a build failure.
When build failure metrics are set up, the interface will look like:
When a build fails because of the bad metric value, it looks like this:
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, which is about to be released in the nearest future.
Twitts about TeamCity