Child pages
  • Hajipur 9.1 EAP1 (build 35957) Release Notes

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Table of Contents

Specifying TeamCity data directory on the TeamCity first start page

Configuration of TeamCity data directory has been moved from the installation wizard to TeamCity startup screens. We hope it will improve the first time installation experience on non-Windows platforms.
The TeamCity data directory path specified on startup screens will be stored in <TeamCity installation directory>/conf/some path.
If environment variable TEAMCITY_DATA_PATH is specified, then for compatibility reasons, value of this variable will be used as path to data directory.

Versioned project settings in Subversion and Perforce

Starting from this EAP, TeamCity allows storing the project configuration settings in a Subversion and Perforce version control repository. Previously, the only supported version controls were Git and Mercurial.

By default, the settings are stored in the .teamcity in the root of the repository. If you wish to change the path used by TeamCity, you can create a special VCS Root dedicated to the VCS settings storage, and specify the path as you want there.

Note that if settings are changed via user interface a commit in VCS will be performed on behalf of the user specified in VCS root. However commit message will also contain username of the TeamCity user who made UI change:

Image Added

Hide If
actionview

For example, in case with Perforce TeamCity will use the .teamcity directory relative to the client you configured; e.g. to store the settings in //depot/some/path/.teamcity

...

folder,

...

specify

...

the

...

Perforce

...

mapping

...

as

...

follows:

Administrator-defined

...

ordering

...

of

...

projects

...

and

...

build

...

configurations

...

By

...

default,

...

TeamCity

...

displays

...

projects,

...

their

...

subprojects

...

and

...

build

...

configurations

...

on

...

the

...

Projects

...

Overview

...

page

...

in

...

alphabetical

...

order.

...


Currently

...

each

...

user

...

can

...

define

...

the

...

order

...

to

...

their

...

liking

...

on

...

the

...

Overview

...

page

...

using

...

the

...

up-down

...

button

...

on

...

the

...

Configure

...

Visible

...

Projects

...

pop-up.

...

However,

...

a

...

unified

...

approach

...

might

...

be

...

needed

...

for

...

a

...

team,

...

and

...

now

...

project

...

administrators

...

can

...

apply

...

custom

...

ordering:

...

you

...

can

...

now

...

reorder

...

subprojects,

...

build

...

configurations,

...

and

...

templates

...

of

...

a

...

project

...

on

...

the

...

Project

...

Settings

...

page.

...

Create

...

build

...

configuration

...

from

...

URL

...

In

...

addition

...

to

...

creating

...

a

...

project

...

from

...

URL

...

,

...

TeamСity

...

now

...

comes

...

with

...

an

...

option

...

to

...

create

...

a

...

build

...

configuration

...

from

...

a

...

VCS

...

URL.

...

All

...

you

...

need

...

to

...

do

...

is

...

enter

...

a

...

VCS

...

URL

...

in

...

the

...

create

...

configuration

...

wizard,

...

select

...

default

...

options

...

to

...

create

...

build

...

configurations

...

and

...

that's

...

it!

...

Schedule trigger improvements

TeamCity has different triggers suitable for various use cases. While many use cases are already covered, still we hear more and more complains about other scenarios which are hard to automate. This is especially true for scenarios when build chain should be continued automatically based on some event. Traditionally we recommend using Finish build trigger if chain should be continued once some build in the chain finishes. However, Finish build trigger is very limited. It does not allow to specify all the same options which we have for dependencies - tags, pin/unpin status, branch, etc. Also, it fires once the build finishes, however in many scenarios this is undesirable. Instead, it would be better to wait for some time before continuing chain, or continue chain only once or twice a day.

Since Schedule trigger already has notion of time, it seemed more appropriate to extend this trigger instead of adding new options to Finish Build trigger. In this EAP build Schedule trigger has got ability to watch for builds in other build configurations and trigger if these builds change. The build is defined the same way as in artifact dependency, with all the same options.

Image Added

The trigger above activates at 8:00 am MSK and checks whether a build in BuildDist build configuration with tag "bs-deploy" has changed. And if it changed, trigger will put a build in queue. Note that build of BuildDist will be promoted to triggered build if there is an artifact or snapshot dependency on BuildDist in configuration where trigger is defined.

New options should cover the following feature requests:

  • TW-4799 - option for scheduled trigger to do not run a build if artifact-dependency build has failed
  • TW-11553 - option to trigger a build when artifact it depends on changes
  • TW-14975 - option in schedule trigger to run a build with changes corresponding to last successful snapshot dependency build

SSH Agent build feature

Other Improvements

  • UI improvements including the chains page
  • Merged MSTest & VSTest plugins (in progress)
  • Support for multiple VCS usernames (in progress))
  • Support for Maven 3.3.1
  • Support for Gradle 2.4
  • Support for Visual Studio 2015 and Microsoft Build Tools 2015 preview in MSBuild and Visual Studio Solution runners, as well as MSTest 2015 (14.0), VSTest 2015 (14.0)(question)
  • The default Subversion working copy format has been changed to 1.8
  • logging preset selected on Diagnostics page is preserved on server restart
  • fixed issues