Several important improvements and bug fixes have been made in project groups feature.
- projects hierarchy is shown on Administration -> Projects page the same way as it shown in the Projects popup
- Configure Visible Projects dialog has become aware of project hierarchy
- projects hierarchy is shown on Administration -> Disk usage page
- projects hierarchy is shown in all drop downs where a list of projects or configurations is displayed
- investigations page for a project also shows all investigations from sub-projects. The same applies to muted problems page, current problems, build chains and project change log. All these pages will show sub-projects too.
- notification rule defined for a project will be effective for sub-projects too
- builds schedule page for a project shows schedule from sub-projects too
- it is now possible to define cleanup rules for projects, such cleanup rules serve as default for configurations from this project and sub project. Default cleanup rule is replaced with cleanup rule in Root project.
External IDs for build configuration and template
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:
- if you're using dependency parameters, you can use external IDs there instead of cryptic btXXX:
dep.<my build configuration external id>.build.number
- you can access build artifacts using a URL like this:
http://<host>/repository/download/<my build configuration external id>/lastSuccessful/artifact.zip
- external ID can be used when build is triggered by HTTP request and in REST requests
Project configuration files changes
We continue refactoring the way configuration files are stored on disk under TeamCity data directory. This EAP brings two important changes:
- from now on, build configuration internal ID is no longer stored in project configuration files, external ID is used instead, the same applies to build configuration template.
- since all VCS roots now belong to projects we removed the global
vcs-roots.xmlfile and moved VCS roots settings to corresponding projects.
Meta-runner is a Build Runner which acts as a combination of one or more build runners and has user interface targeted to user domain. For example, it is possible to configure build step based on Ant to upload some file to ftp. You can move this build step in some template, replace host, user and password with parameter references (%host%, %user%), and then reuse this template in several build configurations. This approach gives some flexibility, but is not very user friendly. Isn't it better to have a dedicated build runner for this task with specific user interface? This is what Meta-runner about.
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. Let's try to create a build runner based on Ant ReplaceRegExp task with the following parameters in user interface:
- pattern to search in files
- replacement string
- patterns for files where replacement must be performed
First of all I need to create a build configuration with Ant build step and with replace target that will do all the work. I'll use the following custom build xml:
Note that in several places I used parameter references:
- %pattern_to_replace% - regexp pattern to search in files
- %substitution% - substitution string
- %basedir% - base directory where to perform replacement
- %files_to_include% and %files_to_exclude% - Ant include / exclude patterns for files
In a 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 for 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:
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.
Queued build page
Dependencies progress has been added on queued build page, you can now see estimates for all dependencies in one place.
Disk usage report
Disk usage report has become aware of projects hierarchy. You can see how much disk space is taken by the project as a whole, and also drill down to sub-projects and see what sub-project uses most of disk space.
Additionally, one more server health report is now provided based on disk usage. This report shows configurations with huge log files, as well as links to builds having these 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.
Branch filters in triggers
VCS and Schedule trigger 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
Mercurial subrepo improvements
- better UI for subrepo graphs
- Server ID - we need some way to remove duplicate usage statistics reports from our database. To be able to do it we introduced a unique identifier - server ID, which is sent together with usage statistics report. This ID is completely anonymous and does not contain machine-specific information.
- Schedule trigger now supports defining time to trigger in a specific timezone.