- Moving projects from one server to another
- Favorite Builds
- Managing custom charts from the TeamCity Web UI
- Create build configuration from Meta-Runner
- Settings in Version Control
- 7-zip support for published artifacts
- Set parameters to dependent builds
- Other Improvements
Moving projects from one server to another
Ability to export and import projects is a quite popular request in our tracker. We worked hard to bring this feature in 9.0, and this EAP build is the first one where you can finally try this functionality.
The import is possible from the Projects Import page in the Administration area.
To start importing projects you need:
- create a usual backup file on the source TeamCity server containing the projects to be imported (note that the versions of the source and target TeamCity servers have to be the same)
- put the backup file into the
<TeamCity Data Directory>/importdirectory on the target server
- follow the import steps on the Administration| Projects Import page.
The projects import feature allows you to select the import scope: you can import project settings, builds and changes history, and user accounts. Since the imported project can also use settings from parent projects, TeamCity will also import all the vcs roots, templates, meta-runners and other project related settings for parent projects. If the same project already exists on the target server, the existing objects will not be overwritten.
For now there are still some important limitations:
- the backup files do not contain artifacts, so artifacts are not imported automatically; the same applies to build logs, because since version 9.0 build logs are stored under build artifacts
- audit records are not imported
- personal changes patches corresponding to personal builds are not imported
- if imported users had roles which are not defined on the new server, these roles will not be imported
- backup files do not contain running builds and the build queue, as a result they are not imported either
- projects import can take some time; for now its performance still requires some improvements
- there can be only one import process per server
Moving artifacts and logs
Despite the fact that TeamCity can't import artifacts and logs right from the backup file, there is still a way to copy/move them from the source to the target server. Each import process creates the
projectsImport-<date> directory under TeamCity logs and as the final step of the import,
.sh scripts for copying artifacts will be generated and placed under this directory. These scripts accept the source and target data directories via the command line. The rest is done automatically. These scripts can be executed while the server is running.
- since projects import is a potentially dangerous operation, we added a separate permission for it available to system administrators by default.
- if users import is selected, and if users imported from the backup file had the system administrator role on the source server, they will be system administrators on the target server as well; if an imported user belonged to some group and there is a group with the same ID on the target, the imported user will be associated with this group, thus potentially getting more permissions.
Starting from this EAP, to easily access builds you want to monitor, you can mark them as favorite. Any manually triggered build will be marked as favorite automatically. The marked builds will be listed on the "My Favorite Builds" page. In addition, notification rules can be configured for such builds.
Managing custom charts from the TeamCity Web UI
Before this build, you could manage your custom charts by manually modifying the
TeamCity Data Directory
>/pluginData/plugin-settings.xml file. Now you can create a new chart:
- on the Statistics tab for a project or build configuration using the Add new chart button.
- on the Parameters tab of the build results page, where the list of Reported statistic values provides checkboxes to select the statistic value for a new project- or build-configuration-level chart.
More details on this feature are available in our documentation.
Create build configuration from Meta-Runner
Currently to change a Meta-Runner you have to edit xml file. This is a error-prone process. Not to mention that if a Meta-Runner is already used, changing it without the ability to test it first may fail a lot of builds. To make this process easier, we introduced an ability to create a build configuration from a Meta-Runner. Once the build configuration is created, you can change its steps, adjust parameters and requirements, check how it works, and then extract into a Meta-Runner with the same ID.
Settings in Version Control
The Change log tab listing all changes in the VCS root where project settings are stored has been added to "Versioned Settings" page.
In addition, you can now disable showing settings changes in builds.
New options were introduced for Perforce VCS roots:
- TW-38323 - support for
p4 cleanintroduced in Perforce 2014.1
- TW-37673 - added ability to provide extra p4 sync options, like
- We've added an internal property to avoid clean checkout when Perforce client mapping is modified, please see this comment.
7-zip support for published artifacts
TeamCity can now compress published artifacts to a 7-zip archive:
**/* => dist.7z
As with other supported compression algorithms you can also specify artifact dependency for files inside a 7-zip archive:
Browsing inside 7-zip archives is also supported. But for now we do not support browsing inside 7-zip placed into another 7-zip archive.
Set parameters to dependent builds
If you worked with TeamCity snapshot dependencies, you probably know about dep. parameters. So if the build configuration with ID A has a snapshot dependency on the build configuration with ID B, build in A can reference B parameter using the syntax:
But sometimes when you start a chain, you want to push a parameter to some or all chain nodes from the top build. It is now possible in this EAP build. With the example above, if you want to start a chain B -> A and push the parameter
param to B, you can add a parameter with the name
dep.B.param to A, either in a custom build dialog or via build configuration parameters. If you want to push parameters to all dependencies, you can use
dep.* in the parameter name:
- fixed issues
- instead of old school DTD files for project configuration files, TeamCity now uses XML schema: http://www.jetbrains.com/teamcity/schemas/9.0/project-config.xsd
- added ability to filter changes by revision on the Change Log page
- Java web start agent installation package is removed from the distribution
- "Use mirrors" option has been added to Git VCS root settings page (previously was available via a configuration parameter)
- "Use mirrors" option has been added to Mercurial VCS root settings page (https://youtrack.jetbrains.com/issue/TW-38557)
- better git/hg progress reporting for agent-side checkout, now all executed commands are shown in a build log