"'Fixed in build" and multiple branches

Hello,
I'm not quite sure I understand what you mean by "was assigned to branch 1.6", but generally there are two opportunities to set fixed in build field for an issue which is in resolved state:

• mentioned it explicitly in a commit message
  
• check Process Resolved Issues option in build mapping configuration. This would mean that a build field will be set (and a command will be applied if specified) to each issue that was resolved prior to the build but after a previous one

What kind of difficulty are you experiencing at the moment?

Best regards,
  Alexander

Thanks Alexander.

Well, first I can't get any build numbers to be set. I have configured the mapping in two ways, both with and without the Apply Command. Its not clear to me whether I need the Apply Command when the Build Field is set and that all I want done.




But my other issue is a bit more involved. Let me try to explain.

Suppose we have two active branches, one for production and one for development. Lets call them 1.5 and 1.6. The business can create an issue and assign the Fix Version to either 1.5 or 1.6.

@t1: issue I-100 Fix Version is set to 1.5, issue I-101 Fix Version is set to 1.6
@t2: both issues are marked as Fixed
@t3: in teamcity the 1.5 branch is built, say build 200

So my question is what will YT do? Will it assign the build number 200 to /both/ issues? Because the code for I-101 was not included in the build since it was the 1.5 branch.

Does this make more sense?

• barry
  

Barry,
Sorry for not responding earlier.

Regarding the first one.
In your scenario you don't need to provide any command to get your Fixed in build field populated. Please check if the following conditions are true:

• your builds in TeamCity are green (or check the respective option in build configuration mapping dialog in case you wish to process all builds)
  
• the builds from TeamCity are automaticaly added to the bundle of Fixed in build field
  
• the configuration maintainer (user 'build') has permission to update Fixed in build field in your project

Regarding the second one.
In case you check Process resolved issues' option, the build field of an issue will be populated with the number of TeamCity build that was the first to assemble after the issue got fixed regardless of a branch the build was assembled from.
Scenario: you have I-500 in unresolved state. At 1pm Build1 is assembled - nothing happens. At 2pm you resolve the issue. At 3pm Build2 is assembled. Build2 will be set to Fixed in build field.

Please also mind that we plan to add more comprehensive support for branches (hopefully, in YouTrack 4.2). Here's the respective issue: JT-7079. Please feel free to participate in the discussion.

Regards,
  Alexander

Wow, I was /just/ showing our "customer" how the build numbers number and how he can see which issues are fixed for a build. And also how that doesn't work in our case because issues get tagged with build numbers from the wrong branch.

The issue with the builder not getting set has been resolved. While doing the above I noticed that build numbers /are/ getting set for issues (but they are wrong the wrong numbers). I have no idea why it started to work.

We do check Process resolved issues. This is because we don't always don't the issue is resolved when doing a commit. I suppose if we did not do that and required the status be set via commit issue the correct build number would get set. But since we don't really work that way, we would end up having to create dummy commits after seeing that a build was not assigned.

I'll check JT-7079 to see how it may handle my scenario.

Thanks!

• barry
  

Hmm, looks like these branch issues are 2 years old. Not very reassuring that there will be any solution in the near future.

yes, the issue is old indeed, but it will be implemented soon

Barry,
You don't have to necessarily resolve an issue by a command from commit to make this work. Important here is that issue ID is "mentioned" in build. This means there's a change containing it or build comment (can be added in TeamCity) contains issue ID.

Alexander

Yes, but then there will be no distinction between an issue being complete in a build vs just some bits of code related to the issue being in the build. Since we want to the customer to be able to determine what to validate, we need the former.

there's an important distinction: resolved status. Only resolved issues will get their fixed in build value. I know, 'Process resolved issues' sounds a bit confusing (and we have a request to change it:)), but it just means 'any resolved issue, not only that mentioned in a commit comment'.

Any new status on this? JT-7079 seems to have not moved in the last 6 months.