Automatic Build Breaks if Occuring After a Manual Build Using Version File

Question

A bit of background...

 

We have a nightly build that runs automatically every night that we also occasionally use for building bootleg releases of our product.  Recently we introduced custom build number that that gives our nightly builds a build number in the form W.X.Y.Z, where Z is automatically incremented after every nightly build.  One implementation detail that might be important is that the build number is tracked in an XML file that is updated with every build.  This build version file is checked-in as part of the build and stored in the TeamBuildTypes directory so we have access to it early in the build process. 

 

And the issue...

 

What we've found is that if we manually queue a build, then don't make any other changes before the next automatically queued build the automatic build will fail because it tries to use the same build number.  The build fails because it attempts to use the same build number as the manual build, almost like it's ignoring the check-in the manual build did to the version file.  The basic sequence the fails is:

 

1) Make a change.  (Changeset 244079)

2) Manually queue a build, which would get a label like 2.0.7.29.  The version file gets updated as changeset 244088.

3) Wait for the automated build, which fails because the label 2.0.7.29 already exists.

 

From looking at the log that we store on the build machine it looks like the automatic build was setting SourceGetVersion to changeset 244079, which wouldn't have included the version file check-in.  Why isn't it using the newer changeset 244088, is it because of ***NO_CI***?  Is this a known issue?

Answer 1

Hi Jasonsto,

Thanks for your post.

There is a similar issue mentioned in the following blog: http://blogs.microsoft.co.il/blogs/srlteam/archive/2009/01/26/version-number-not-latest-when-running-a-build-with-custom-build-number-running-on-tfs-2008.aspx

A workaround is to override the GetVersion property to:

<GetVersion>T</GetVersion>

Not sure if it is the same case as yours, but please have a try and let me know the result.

Have a nice day.

 

Hongye Sun [MSFT]
MSDN Subscriber Support in Forum
If you have any feedback on our support, please contact msdnmg @ microsoft.com

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Answer 2

Hi Hongye,

Thank you for your response.  I thought for sure that would solve the issue, but it doesn't.  I added "/t:GetVersion=T" to my response file, but the build still broke with the same error.  I think the issue is that the BuildType directory is getting populated with an old version, this occurs even before we execute the Get target.  If I override "SourceGetVersion=T" in my response file would that cause the BuildType directory to get populated with the latest code?  Do you have any other ideas? 

This seems like a defect in Team Build since changeset 244088 (in my example above) exists before the automatically triggered build is queued.

Regards,
Jason

Answer 3

Folks,

I've spent the last few days reading up on the ***NO_CI*** flag, scheduled builds, and some changes that were implemented in SP1.  Basically what I've learnt is:
1) In SP1 a change was made so that scheduled builds "ignore" the ***NO_CI** just like check-in builds did in the past.
2) Manually queuing a scheduled build doesn't "clean out" the pending changes and the scheduled build will still run at its designated time after the manual build.  (Even though the associated change sets for the automatically queued build might not reflect that.)

What I'm observing is a scheduled build is being triggered, but populating it's $(BuildDirectory)/BuildType folder with old source code.  Shouldn't this directory be populated with the latest source code, even if that latest source code was checked in with the ***NO_CI*** flag?

This behavior can be reproduced using the following steps:
1) Create a new build definition
2) Manually queue a build for the new build definition and wait for the build to complete.
3) Set a scheduled time for the build to execute.  Make sure to schedule it ~10 minutes out to give yourself time to complete the next two steps.
4) Make a change to the source code that the build will pick up.  Check-in the source code (do not use the ***NO_CI*** flag).
5) Make a change to the build's TFSBuild.proj (keep it simple, maybe just a short comment).  Check-in the change using ***NO_CI***.
6) Wait for the automatically queued build to complete.
7) Inspect the $(BuildDirectory)/BuildType/TFSBuild.proj file on the build machine, it won't include the change that you performed in step 5.

Any help would be greatly appreciated.

Regards,
Jason