Several important improvements and bug fixes have been were made in project groups feature.
- "Configure Visible Projects" dialog has become made aware of project hierarchy
- projects hierarchy is shown on Administration -> Projects page in the same way as it is shown in the Projects popup
- 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 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 its sub project-projects. Default cleanup rule is replaced with cleanup rule in now defined in the Root project.
VCS roots and templates
There is no notion of shared VCS root anymore. If a VCS root should be available to several projects it should be moved to the common parent of these projects or to the Root project. Thus Therefore, when you upgrade to this EAP build, all shared VCS roots will be moved to the Root project.
The same applies to templates , - build configuration can be attached to a template if the template belongs to project of this configuration or to one of parent projectsthe parent project. This means that starting with this EAP you won't be able to use a template from a 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:
- 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
We continue refactoring the way how 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 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 can generalize them, i.e. replace some hard coded hardcoded 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 the nature of templates 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.
Now we need to associate labels and descriptions with these those parameters, this can be done through regular parameter editing dialog.
Once we 've described the parameters we can extract a meta-runner from the build steps page of the build configuration:
Upon clicking on "Extract" button TeamCity will take definitions of all build steps, parameters, and requirements in this configuration and create a build runner out of them. In this example we did not use requirements, so extracted runner will not have them. However if runner depends on some specific software installed on agent, we could define requirements in configuration for this software, and these requirements would be extracted in meta runner too.
- when meta-runner is extracted from the web interface there is no way to specify which steps you want to extract, all defined build steps will be extracted
- extract meta-runner interface UI does not allow to reorder parameters, you have to change order manually in meta runner file
- meta-runner definitions are global for the server, there is no way to store them in some project only
Queued build page
Dependencies progress has been was added on queued build page, you can now see estimates for all dependencies in one place.
VCS, Schedule and Finish build triggers have got a 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
We continue improving usability of Mercurial subrepositories subrepo changes. To be able to distinguish main repository changes and subrepository changes changes from subrepositories now have additional Changes from subrepositories are marked with an icon:
Note: on On this screenshot you can also see another new feature: dashed lines from change in that visually connect changes in the 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
Last but not least, change graph can be collapsed into a single line:
- Server ID - to be able to remove duplicates from our usage statistics reports we need to identify server the servers somehow. To be able to do it With that in mind, 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 time can be set in a specific timezone.
- Builds schedule report allows to filter data by sub-projects
- Build problems UI has got several improvements, notifications for build problems investigations are now supported
- For build rows on Pin and tag status is shown for builds on the change log page pin and tag status are now shown