See also Indore 2017.2 EAP1 (build 49391) Release Notes
In this EAP we’re introducing a new kind of a build configuration - a composite one. The purpose of this build configuration is to aggregate results from several other builds combined by snapshot dependencies and present them in a single place.
When creating a build configuration, you can now select the build configuration type:
There are important differences between such build configurations and usual configurations with snapshot dependencies:
On the build chain view TeamCity also automatically hides all of the dependencies of the a composite build, showing a single node for such builds by default.Since this build behaves like a single build, it is possible to create a notification rule on “Build starts” or “The first build error occurs” event and get a notification when the first dependency starts or reports a build problem.To some extent, a composite build can be viewed as a build which consists of a number of parts which can be executed in parallel on different agents. All these parts will have synchronized snapshot of the source code and the results can be seen in a single place.
In the previous EAP we announced the initial support for Docker. This EAP brings the following improvements:
When a process is run under Docker in the Linux environment, the owner of the created files is root and the files created by a step with the Docker Wrapper may be not writable by the parent build agent process. Rather than setting
umask 0 (as it was done in the previous EAP), access to such files is restored by the
"chown -R buildAgentUserId <checkout directory>" command automatically run by TeamCity at the end of the build step with Docker Wrapper.
The Docker Support build feature now provides 2 new options:
These options require a configured connection to a docker registry: on the Project Settings > Connections page you can now configure an authorized connection to docker.io (default) or a private Docker registry. More than one connection can be added to the project.
If you have a build configuration which publishes images, you need to remove them at some point. You can select the corresponding option and instruct TeamCity to remove the images published by a certain build when the build itself is cleaned up. It works as follows: when an image is published, TeamCity stores the information about the registry of the images published by the build. On cleaning up a build, all the configured connections are searched for the address of this registry and the images published by the build are cleaned up using the credentials specified in the found connection.
If you need to log in to a registry requiring authentication before a build, select the corresponding option and a connection to Docker configured in the project settings. Automatic logout will be performed after the build finishes.
Now when a new plugin is uploaded to the server, it is displayed on the Administration | Plugins List page. If the uploaded plugin overwrites an existing one, a note is displayed warning the administrator that the plugin will be overwritten.The uploaded plugins are displayed, but they will be installed and enabled only after the server restart.
Starting from this version, any plugin can be disabled using the TeamCity UI: on the Administration | Plugins List page every external plugins has a button, clicking which opens a popup with the corresponding option; the bundled plugins have a link which can be used to disable them. On disabling a plugin, a warning is displayed that this may impact other TeamCity components (e.g. other plugins). During the next server restart, the disabled plugin is not loaded. If there are other plugins depending on the disabled one, they will not be loaded either. Disabled plugins are greyed out in the list.
We’re also working on the TeamCity auto-update feature, which should further enhance your upgrade experience. TeamCity server startup scripts have been reworked significantly to handle the automatic upgrade process. There is also the Administration -> Update page which will show new versions of TeamCity where you can start the server upgrade process. One of the bonuses of developing this feature was implementation of the “Restart Server” button, which was announced in the previous EAP. We hope that this will make the upgrade of your server to the next EAP build much simpler.
The TeamCity Audit log now contains information on including / excluding roles and adding / deleting permissions
Now TeamCity will automatically terminate a long running TFS app in case of inactivity ( e.g. a user just wanted to test a TeamCity TFS connection) and when a certain run time is exceeded (e.g. to address memory leaks).
These periods are controlled by the following configurable properties:
e defaults to 30 min
eamcity.tfs.java.long.living.process.lifeTime is disabled by default
REST API now allows investigations assignment