4

I am using TFS2010 with gated check-ins, and even though I have set "Associate Chagesets and Work Items" to false, changesets and work items are associated with this build.

This happens only on gated builds. If I run build with other check-in triggers (manual, continuous, schedule), changesets and work items are not associated with the build unless "Associate Changesets and Work Items" is set to true.

Any ideas why this is happening? I'm using Visual Studio Scrum process template with default workflow definitions. Maybe there is problem in workflow definition?

CJBS
  • 15,147
  • 6
  • 86
  • 135
Zvonko
  • 363
  • 2
  • 19

1 Answers1

2

Gated-CheckIn builds are associated with the check-in changeset and the related work items by default. This Boolean parameter decides whether a non-Gated-CheckIn build should have the changesets and work items associated.

If you look at the default template, you'll see the AssociateChangesetsAndWorkItems activity is invoked when this parameter set to true the the build reason is not Gated-CheckIn. The display name says it: "Associate Changesets and Work Items for non-Shelveset Builds".

I think the description of this parameter is misleading. It says: "Set this to true to associate changesets and work items to the build". It should say "to the non-gated-checkin build".

Duat Le
  • 3,586
  • 2
  • 19
  • 18
  • I see. I also found the place in default template which handle this. I've tried to add CheckInShelveset to the Reason list, but whithout success. How can I prevent associating chagesets and work items with gated check-in builds? – Zvonko Jan 23 '12 at 16:31
  • I have also removed the AssociateChagesetsAndWorkItems activity from the template and still the same. When gated checkin is build the work items and chagesets are still associated with the build. How can I prevent this? Or is this default TFS behavior which cannot be changed? – Zvonko Jan 30 '12 at 07:57
  • This is the default behavior for Gated-Checkin build definitions. I believe it is done in the CheckInGatedChanges activity and I don't think you can prevent it. Can you tell me why you need the gated-checkin build to not associate the changeset and workitems to the build? – Duat Le Jan 30 '12 at 14:08
  • I have "release build" which is responsible for building a full release of the software, including setup, database upgrade scripts, etc. Part of this build is also creating a list of changes between releases. This list is done on a basis of associated work items - work items, associated with build are added to the change log of that build. If the changes are associated with gated checkin, i cannot generate the change log based on "release build". – Zvonko Jan 30 '12 at 15:54
  • I did some more research and association of work items and changesets is hardcoded in CheckInGatedChanges activity. So there are two options, first creating my own activity for gated check-in and second, change the way the release "change log" is generated. – Zvonko Jan 31 '12 at 08:05
  • 1
    I'm not entirely clear on what you described. Work items can be associated with more than just one build, can't they? – Duat Le Jan 31 '12 at 14:05
  • @Duat, yes, they are associated with more than one build. – jessehouwing Jun 03 '12 at 15:59
  • To override the default behaviour and achieve the correct behaviour you will need to build your own customized build template: http://msdn.microsoft.com/en-us/library/dd647551.aspx – Russell Horwood Sep 11 '14 at 14:11