Several important improvements and bug fixes have been made in project groups feature.
There is no notion of shared VCS root anymore. If VCS root should be available to several projects it should be moved to common parent of these projects or to Root project. Thus when you upgrade to this EAP build, all shared VCS roots will be moved to Root project.
The same applies to templates, build configuration can be attached to a template if template belongs to project of this configuration or to one of parent projects. This means that starting with this EAP you won't be able to use template from separate project hierarchy. However, as this was possible before, TeamCity will still support this case and will load such configurations without errors.
It is now possible to define external ID for build configuration or template. It works the same way as external ID for project, i.e. it is used in URLs instead of internal ID, and it is used in configuration files. However with build configuration external IDs add some additional benefits:
dep.<my build configuration external id>.build.number
http://<host>/repository/download/<my build configuration external id>/lastSuccessful/artifact.zip
Read more about using external IDs when accessing server by HTTP in our documentation: Accessing Server by HTTP, Patterns For Accessing Build Artifacts
We continue refactoring the way how configuration files are stored on disk under TeamCity data directory. This EAP brings two important changes:
vcs-roots.xmlfile and moved VCS roots settings to corresponding projects.
Meta-runner is a Build Runner acting as a combination of one or more build runners and having user interface targeted to user domain. For example, you can define one or more build steps in some build configuration to solve some specific task. Now if you need to reuse this set of steps, you should generalize them, i.e. replace some hard coded values with parameter references and create a template with this set of steps. Then you can reuse this template in several configurations. However, due to template nature this approach is still not flexible enough. Template brings a lot more settings in your configuration, and many of them you might not want to reuse. It would be great to be able to reuse this set of build steps only, preferably as a dedicated runner with own web interface, and this is where Meta-runner comes into play.
Let's see how it works. Sometimes during the build process we need to replace some pattern in several files before making a distribution package. For example, if you build a TeamCity plugin you need to provide build number in teamcity-plugin.xml file bundled with the plugin. So this build runner should have the following parameters:
First of all I need to create a build configuration with Ant build step. I will use Ant built-in replaceregexp task to do all the work, so my build.xml will look like this:
<project default="replace" name="ReplaceRegExp"> <target name="replace"> <replaceregexp flags="g"> <regexp pattern="%pattern_to_replace%"/> <substitution expression="%substitution%"/> <fileset dir="%basedir%"> <include name="%files_to_include%"/> <exclude name="%files_to_exclude%"/> </fileset> </replaceregexp> </target> </project>
Note that in several places I used parameter references:
In the build configuration where this Ant build step is defined I will see these parameter references as undefined parameters on Build parameters tab, because no one provided values for them.
Now we need to associate labels and descriptions with these parameters, this can be done through regular parameter editing dialog.
Once we've described parameters we can extract meta runner:
And use it in some other build configuration:
Definitions of meta runners are stored under
TeamCity Data Directory/config/_meta_runners/ directory. Here is complete definition for Replace in Files build runner (I added validation regexp for parameter values and reordered parameters):
<?xml version="1.0" encoding="UTF-8"?> <meta-runner name="Replace by Pattern"> <description>Replace in files by pattern</description> <settings> <parameters> <param name="basedir" value="" spec="text display='normal' label='Directory where to perform replacement:'" /> <param name="pattern_to_replace" value="" spec="text display='normal' label='Pattern to replace:'" /> <param name="substitution" value="" spec="text display='normal' label='Substitution:'" /> <param name="files_to_include" value="" spec="text display='normal' label='Files to include (Ant patterns):'" /> <param name="files_to_exclude" value="" spec="text display='normal' label='Files to exclude (Ant patterns):'" /> </parameters> <build-runners> <runner name="" type="Ant"> <parameters> <param name="build-file"><![CDATA[<project default="replace" name="ReplaceRegExp"> <target name="replace"> <touch> <fileset dir="%basedir%"> <include name="%files_to_include%"/> <exclude name="%files_to_exclude%"/> </fileset> </touch> <replaceregexp flags="g"> <regexp pattern="%pattern_to_replace%"/> <substitution expression="%substitution%"/> <fileset dir="%basedir%"> <include name="%files_to_include%"/> <exclude name="%files_to_exclude%"/> </fileset> </replaceregexp> </target> </project>]]></param> <param name="build-file-path" value="build.xml" /> <param name="teamcity.step.mode" value="default" /> <param name="use-custom-build-file" value="true" /> </parameters> </runner> </build-runners> </settings> </meta-runner>
In order to install this build runner in your TeamCity installation you need to save this definition to a file under
TeamCity Data Directory/config/_meta_runners/ directory. File should have name like:
<runner id>.xml, where <runner id> is unique identifier of this build runner. Server will detect this definition and will load it on the fly.
Dependencies progress has been added on queued build page, you can now see estimates for all dependencies in one place.
This report shows builds with huge log files. Huge (hundreds of megabytes) build logs are rarely useful, it is hard to analyze them and in most of cases they just waste space on disk. We hope this report will help to find configurations that produce such log files and fix them.
This report finds incorrect settings of Swabra build feature which can cause unnecessary clean checkout.
VCS, Schedule and Finish build triggers have got new setting: Branch filter. With the help of the new filter you can limit the set of branches where automatic triggering will be performed. Read more about branch filters in our documentation: Working with Feature Branches#Triggers
We continue improving usability of Mercurial subrepositories changes. To be able to distinguish main repository changes and subrepository changes changes from subrepositories now have additional icon:
Note: on this screenshot you can also see another feature: dashed lines from change in main repository to changes in subrepositories. These dashed lines are shown if you click on the change in main repository in commits graph.
One more improvement in graph of commits allows to collapse VCS root commits into single line: