The user interface update that we started in the previous version continues in the future 2018.1 version.
In this EAP build the build line has been redesigned a bit and agent history page now looks similar to "All builds page" (which was introduced in 2017.2.x):
We're working on other pages where lists of builds are shown. Expect more changes in the next EAP build.
In the current TeamCity version, if a build step is defined in a template, it is shown as read-only in a build configuration inheriting this build step. If some customization is required, then a parameter reference has to be defined for some settings in the template, and a specific value should be set for this parameter in the build configuration. However, this workaround works for text fields only.
In this EAP it is finally possible to customize an inherited build step, i.e. it is possible to change every setting of the inherited build step without the need to introduce parameters.
Note that the redefined build step preserves its place in the steps order. Note that overriding any property in an inherited BC will fix all the other values in the resulting build config, and changing other properties of the same feature in a template will not take affect. It concerns build steps, triggers, build features, artifact deps, agent reqs, failure conditions.
There is sometimes a need to define a common build step in a template, so that this step will be executed either before all build configuration steps or after them.
In this EAP build, for a given template it is possible to define such steps and then define their placement in respect to the build configuration steps. All build configuration steps are represented as a placeholder in the Reorder Build Steps dialog. The template steps can be placed before or after this placeholder.
Note: you still can have a completely custom order of steps in a build configuration inherited from a template.
Now it’s possible to assign a template to some project to be Enforced Settings. As for default templates all build configurations under this project will inherit parameters, options and build features from the enforced settings but such settings could not be overwritten or disabled by build configuration own settings nor by template. Other data in enforced settings won’t be applyed for now (runners, triggers, dependencies, etc).
For parameters and options their specs will be forced. So to force a parameter value read-only attribute (“readOnly=’true’”) should be added to its spec.
Only a system administrator can now assign enforced settings to a project. But any user having edit permissions in the project where template used for enforced settings is defined could modify it. So it’s recommended to create enforced settings in a separate project with specific user access and where VCS settings are not enabled or are trusted.
If there are some enforced settings in a project and another template is assigned as enforced settings in a subproject – the second will have higher priority and will overwrite settings from the first one.
Now when re-running a build, TeamCity preserves all the custom parameters of this build and its dependencies as of the time of the original run.
Besides that, on the dependencies tab, there is now an additional option to rerun the failed/failed to start or cancelled dependencies of the build:
Since this EAP shared resources can be locked not only for regular builds, but for composite builds as well. A lock on the specified resource will be acquired when a composite build starts (when the first build of the composite build chain starts); the lock will be released when the composite build finishes (the last build in its chain is finished).
The locks acquired on composite builds affect only these composite builds and are not propagated to their individual parts.
For example, if a resource has a quota of N, then N composite builds that have a read lock on this resource can be run concurrently. The number of concurrent individual builds inside these composite builds will not be affected by the resource quota.
Adding a lock on a composite build is done the same way it is done for a regular build: it can be done by adding the Shared Resources build feature.
Java 9 and Java 10 can now be used to run an agent.
Commit Status Publisher now allows an admin to configure custom values for success and failure instead of +1 and -1 respectively. This label is also configurable. Note that since TeamCity 2018.1 Gerrit 2.6. is the minimal version supported by Commit Status Publisher.