Child pages
  • Indore 2017.2 EAP2 (build 49708) Release Notes
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

See also Indore 2017.2 EAP1 (build 49391) Release Notes


Composite Builds

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:

  • A composite build is shown as running at the same time when the first dependency of the build chain starts, and is shown as finished when the last dependency finishes

  • A composite build does not occupy an agent, as a result some settings which require an agent, like build steps or requirements, are not applicable

  • A composite build aggregates results from dependencies, for instance, it aggregates all of the tests and shows all failed/muted or ignored tests of the chain in a single place

  • The status line of the composite builds reflects the current chain state: the number of running/queued/finished or failed dependencies

  • The progress indicator of the composite build reflects all of the dependencies, so it actually shows when the whole chain is going to finish

  • A composite build often acts as a single build despite the number of dependencies; so for instance, if one decides to stop this build or remove it from the queue, all dependencies are stopped / removed too

  • Another example of a single build behavior is “maximum number of running builds” setting. If for a composite build it is set to 1, then, if some composite build is running, the next one will not start until the previous is finished, which means that dependencies of the next composite build will not start either and so the whole chain will wait till the current one finishes.

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.

Docker Integration Improvements

In the previous EAP we announced the initial support for Docker. This EAP brings the following improvements:

Setting Ownership of Files Created in Checkout Directory

When a process is run under Docker in the Linux environment, the owner of the created files is root. In the first EAP build, the TeamCity Docker Wrapper set umask 0 to make sure all created files are writable by the parent build agent process.

However, if a script running on the docker sets permissions explicitly, the created file may not be writable outside the docker process.

At the same time, setting umask 0 may have unexpected and undesired effect regarding file permissions.

To fix such situations, TeamCity now runs the chown -R buildAgentUserId <checkout directory>  command at the end of the build step with Docker Wrapper. This default behavior can be altered using the teamcity.docker.chown.enabled=false configuration parameter. And umask 0 trick is not used anymore by default, but can be enabled with the teamcity.docker.umask.enabled=true configuration parameter.

Docker Support Build Feature Improvements

Now when configuring this build feature, you can specify:

  • Whether during clean-up TeamCity needs  to delete images pushed to a registry during the build.   

When an image is published, TeamCity stores the information about the registry of the published images. On clean-up, all the configured project connections are searched for the address of this registry and the published images are cleaned up using the credentials specified in the connection.

  • whether to log in to Docker registry before the build: if you need to log in to a registry requiring authentication, here you can select a connection to Docker configured in the project settings.

Configuring Connection to Docker

If you need to log in to an authenticated registry before running a build or if you wish to clean up the published images after the build - these are the options provided by the Docker support build feature (see above) - you can now configure a Docker connection in TeamCity. By default, this connection will be available in all the subprojects and build configurations of the current project.

The Project Settings > Connections page allows you to configure an authorized connection to docker.io (default) or a private Docker registry. More than one connection can be added to the project.

Tracking Newly Uploaded Plugins

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.

Disabling Plugins from UI

Starting from this version, any plugin can be disabled using the TeamCity UI: on the Administration | Plugins List page external plugins have 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.


Other Improvements:

  • 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:
    - teamcity.tfs.java.long.living.process.idleTime  defaults to 30 min
    - teamcity.tfs.java.long.living.process.lifeTime is disabled by default

  • REST API now allows investigations assignment

  • Fixed issues




  • No labels