Map one youtrack project with several configurations in teamcity : JT-6619

Back to Search

Project	YouTrack
Priority	Major
Type	Feature
State	Submitted
Assignee	Alexander Volfman
Subsystem	TeamCity Integration
Fix versions	Backlog
Fixed in builds	No Fixed in build
Affected versions	No Affected versions
Browser	Any Browser
OS	Any OS
Verified in build	Not verified
Verified by	Nobody
Affected builds	No affected builds
Reviewed by	No reviewed by
Story points	Undefined
Value	210
Marketing value	No marketing value

Created by Vadim Gurov
21 months ago (05 Aug 2010 12:19)
Updated by Yegor Yarko
9 days ago (16 May 2012 17:49)

JT-6619 Map one youtrack project with several configurations in teamcity

Issue is visible to: All Users

Links — Show as list

Depends on:
TW-16052

Is duplicated by:
JT-2698

map criteria is fix for version
for example I have two issues with fix for 1.0 and 2.0
and i have two teamcity configurations that builds 1.0 and 2.0
i want to map all issues with fix for 1.0 to teamcity configuration that assembles 1.0
and i want to map all issues with fix for 2.0 to teamcity configuration that assembles 2.0

Kirill Safonov

27 Oct 2011 15:01

6 months ago

I would like to have multiple values in 'fix in build' field, e.g. have my issue fixed in '110.15' which is master branch AND in '109.200' which is my release branch, with no regard which is 'fix for' value for the issue

Vadim Gurov

27 Oct 2011 15:26

6 months ago

Kirill, there are two options to get it:
1. With current 3.0.4 youtrack version, you have to add new field "fixed in build2" with type build[*] and then create two teamcity mappings for release and branch build configurations, defining created "fixed in build2" as Build Field in mapping dialog.
2. Wait for 3.1 and then convert existing "fixed in build" to type build[*] (now it's build[1]), next steps are the same as in option 1.

Kirill Safonov

27 Oct 2011 15:37

6 months ago

OK, I guess 3.1 will be out at the moment we need this. Thanks!

Alexander Volfman

26 Jan 2012 21:01

3 months ago

build[*]->build[1] conversion implemented

Related Changes

Subsystem

No subsystem→ TeamCity Integration

Alexander Volfman

11 Apr 2012 17:16

6 weeks ago

Ok, folks. My vision is the following.

Need to distinguish release and feature branches (RB and FB). Mainline (or develop) can be either RB or FB - see below
YT must have a value in a versions bundle for each RB. YT can have such value for a FB
When a commit mentioning an issue is merged from a RB to a FB, both Fixed in Build and Version fields' values are updated regardless of whether there were any values before
When a commit mentioning an issue is merged from one RB to another, no actions are taken

Configuration/implementation aspects:

From implementation perspective p3 and p4 above mean that actions are to be taken only in case Version field of the issue is empty or contains values referring to any FBs only
The easiest way to implement FBs and RBs support is to allow to tell a TC Build Configuration Mapping that it works with RB or FB. The mapping then will need to be able to set appropriate Version value, which can be running a command
We can also create a special wrapper for Version field value (like we did for Build field) so that it can have a link to TC Build Type
Develop can be a RB (the situation we currently have for JT project). When we decide to create a new branch for 4.0 stabilization, develop should be made a FB

Alexander Volfman

11 Apr 2012 17:21

6 weeks ago

Any feedback on the comment above is highly appreciated.

Yegor Yarko

16 May 2012 17:49

9 days ago

Alexander,

Need to distinguish release and feature branches (RB and FB).

Can you explain why?