Committing files during build with version number change

I reckon this is a FAQ somewhere, please redirect me if it is.

We want to include the TeamCity build number inside our .NET assembly
versions (although the question applies to anything where I'm updating
the build number and then committing that file back to CVS), but are not
sure how to handle the committing of the file without re-triggering a
new build from that commit.

I presume we could work this out by hand, by controlling the
inclusions/exclusions in the build triggers combined with what's pulled
and all that - but I thought this might be a common enough task that
TeamCity would add some value to the equation.

6 comments

Chris,

The most proper configuration for the use case seems to check-in such changes on behalf of particular user and ignore commits of the user in the build triggering rules.

Latest EAP builds (since build 5644) have a special syntax for specifying build triggering rules using committer name.

e.g. you can use rule like:
-:user=builduser:**
to do not trigger a build for commits by user "builduser".

See more on the rules syntax at:
http://www.jetbrains.net/confluence/display/TCD3/ConfiguringBuildTriggers

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

Yegor Yarko (JetBrains) wrote:

Chris,

The most proper configuration for the use case seems to check-in such changes on behalf of particular user and ignore commits of the user in the build triggering rules.

Latest EAP builds (since build 5644) have a special syntax for specifying build triggering rules using committer name.

e.g. you can use rule like:
-:user=builduser:**
to do not trigger a build for commits by user "builduser".



Okay, I've got that working now. (Although rather than ignoring the
build user, I'm just ignoring a specific file in the build trigger)

The only weird side-effect is that the commit is still registered by
TeamCity in its Pending display, and then is included in the Changes of
the next build (when a real one comes along). Since I include the
build number in the commit comment for quick feedback.

So what I see is something like:

My Project
#33 Success Artifacts Changes
|- my.dist.33.zip |-set build number to 32

And I reckon if I did a manual label task, the commit that occurred
during the build wouldn't get labeled with this one.

Maybe I should open a JIRA asking for a way to include commits during
the TeamCity build inside that build, as if it'd pulled the build.

(I suppose I could wire something up myself between two builds - one
build that simply does the build number commit and a second build that
actually is doing the whole thing - but that seems a bit weird).

And I reckon another answer is here, "That's what labeling is for" - but
frankly CVS labels for every in between build clutters up my repository
big-time, causing views like what FishEye gives me to be rendered
useless by all the labeling going on. We've been committing our build
numbers in files for quite a while now and it works great for us - we
don't even label anymore.

0

Chris,

Including changes occurred during the build may be not a good idea, considering TeamCity's ability to run multiple builds at a time. Moreover, the fact is that the build uses the sources actual on the moment of its start, not the ones with the change made from the build script.

Your case of storing the build number in the version control may also fail in some cases: namely if a a commit by some developer gets between the build start and build number check-in time. This can be quite unlikely, but still can occur.

TeamCity labeling functionality, on the other hand, ensures the label is set to the sources used for the build.

The only "guaranteed" way of storing build number in the VCS I can see is as follows: when there is time to start a build, some plugin for TeamCity determines the build number, checks it into the version control, then gets the sources on the revision of the check-in and uses them for a build. Currently, this cannot be easily implemented in TeamCity, mainly because there is no functionality to check-in to the VCS from the server-side. Maybe this type of use case can be addressed in future versions of TeamCity.

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

Do you have any recommendations for including the TeamCity build number
in version numbers in .NET assemblies? So far, I've been working on an
Ant build, where it's easy to simply use the build number from TeamCity
in building manifest data for .jars and tacking on to a deployment filename.

.NET assemblies want the AssemblyInfo.cs file, and we need to keep these
files in source control. Our pre-TeamCity build automation would
increment the build number and re-commit the AssemblyInfo.cs file to CVS.

One option is to still have our pre build script set the build number
portion of the AssemblyVersion inside the AssemblyInfo.cs file and just
leave the modified file there. Would that cause TeamCity problems the
next time it pulls? Or will it do a clean pull, overwriting the local
changes?

Another option is to not use the build number at all, using the 1.0.*
format - but we can't use that for other reasons.

At the moment I'm not seeing a clean way to do this.

0

Chris,

If you use server-side checkout, modifying the file should work fine, provided the script can deal with fresh file form VCS as well as with modified for the previous build. In this case the file will be left as it is (modified from VCS-stored version) until it is modified in the VCS or clean sources - in this cases the file will be overwritten with the VCS version.

If you use clent-side checkout this depends on the version control used. CVS should try to merge the file if it is modified both locally and in the VCS. And SVN update will not update the modified file from the VCS.

A clean solution seems to have AssemblyInfo.cs.template file in the VCS and copy it to AssemblyInfo.cs during the build time, applying all the necessary processing. It seems that if you also have AssemblyInfo.cs file in the version control that won't hurt since the build will create the file from template all the time (but then you must not forget that the build uses AssemblyInfo.cs.template, not AssemblyInfo.cs file).

Hope, this helps.

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

Yegor Yarko (JetBrains) wrote:

A clean solution seems to have AssemblyInfo.cs.template file in the VCS


Ok, cool. I may try that.

0

Please sign in to leave a comment.