TeamCity display version number with TC build number

[RobSmyth]

I've been able to include the TeamCity (TC) build number in the AssemblyInformationVersion (see issue 1358) but now I need TC to show an abbreviated version with the TC build number.

Why? - I need traceability to the TC build as a commit may be build multiple times. Technically I have that but I want the TC UI to shown both the built version, pre-release info, and always the build number.

Withing the Visual Studio solution I've added:

<!-- If being build by TeamCity, notify TC of the version number -->
  <Target Name="TeamCity" AfterTargets="Build" Condition=" '$(TeamCityBuild)'=='true'">
    <GetAssemblyIdentity AssemblyFiles="$(TargetPath)">
      <Output TaskParameter="Assemblies" ItemName="AssemblyIdentity" />
    </GetAssemblyIdentity>
    <Message Text="##teamcity[buildNumber '%(AssemblyIdentity.Version)+Build.$(BUILD_NUMBER)']" />
  </Target>

On a release branch build I get (good):

#1.0.0.0+Build.92

But on a beta build I get something like:

#1.0.0-Beta.1+16

What I want, for a beta build is:

#1.0.0-Beta.Build.92

How can I do this?

[RobSmyth]

I've still not been able to find a solution to this. The "Build" text is not important I would be happy with:

#1.0.0-Beta+92

Or anything similar. The key is to be able to rebuild the same code and still be able to trace it to the specific build so I've got traceability to agents/tools used.

[RobSmyth]

Further info ... I've resolved part of my confusion. It was sort of working until I had added GitVersionTask to one of my test projects. As GitVersion task is sending version info to TeamCity then the last project to build wins. My ##teamcity notification was in a production assembly. So that approach is not usable as it is too brittle.

So while less confusion, the problem remains, how can I include an environment variable (TC build number) in SemVer metadata?

[RobSmyth]

Actually ... a random number would suffice. What I need is a way of uniquely identifying which build built the artifacts. The source code can be rebuilt without further commits.

So, even a random number would suffice. Not elegant but it would o.

[asbjornu]

To me, it sounds like you don't really want the build number in the version number at all, since the functionality you're asking for is the stability of commit_id + branch == version_number that GitVersion provides. What lead you to the conclusion that you need the build number in the version number in the first place?

[RobSmyth]

Hi asbjornu,

You ask

What lead you to the conclusion that you need the build number in the version number in the first place?

The need is to be able to trace compiled code (DLLs, etc) to the TeamCity build. commit_id traces the DLL to the code but not the build as we can build the same code multiple times. Each build may be on different build boxes. If I can include the TeamCity build number then the DLL is traceable to the code and the build.

Does that make sense?

Rob

[asbjornu]

Ok, I think I understand the "what", but not the "why". Please don't take this as critique, I'm only asking because I'm curious and want to understand your requirement better. Since commits in Git are immutable and thus identical regardless of where they are built, why does where the build was performed matter?

[RobSmyth]

Hi,

Sure, the source is the major item but the build may be different due to build time options, libraries, and different installs on build boxes. Also, in Windows .Net development no 2 builds are ever exactly the same (timestamps, signing).

For example a version of a tool, installed on a build box, may have a bug. Also, builds have options such as release/debug, compiler options like optimize for speed/size, parameters, etc. There is also the issue of which framework libraries were used, etc.

This is one of the main reasons we use build boxes. You never know what is on a dev box, hence a release built on a build box.

So each build box can be different. Also, software on build boxes changes over time with updates, so if you want to rebuild the exact software 5 years later the build logs for that build are essential to see which compiler, frameworks, tools, etc.

To conform to FDA requirements for medical software you must be able to trace your artifacts to a particular build.

So the "why" is we need to be able to trace artifacts to builds to mitigate the problems of:

• Multiple builds of software are not always the same when
  • built on different boxes
  • built at different times (updates, etc)
• regulatory requirements may also require the traceability
• Build time options change what is built
• Build system may select different library sources (e.g. local NuGet repository)

I hope that makes sense.

[asbjornu]

@RobSmyth: Thanks for the detailed and elaborate explanation. That was indeed very useful information to have. Now that I understand the requirement, I think being able to format your own version number (related to #1145) would solve the problem. This wish pops up every now and then, and while we have a few -format properties in the configuration, it's still a static set of things you can format.

Perhaps we should add a DSL for the format string? We could for instance do {env.BUILD_NUMBER} to have the BUILD_NUMBER (set in TeamCity to be %build.number%) formatted into whichever -format property you want. Then you get the build counter from TeamCity, GitVersion uses it in its version and GitVersion can update the visible build number in TeamCity with a Service Message. Could that work?

[RobSmyth]

That sounds perfect.

[asbjornu]

If what I describe in #1157 (comment) sounds like a fitting solution to this problem, I propose that we close this as a duplicate of #1157.

[vyruz1986]

Hi @RobSmyth , I'm in a similar situation like yourself, needing to have builds labeled with the SemVer+BuildCounter metadata.

I've been looking into this, and found that with the current way GitVersion is coded, it is not easily done. You can see TeamCity.cs on line 58 is using the FullSemVer variable to update the build number. This is hardcoded so it's not currently possible to ommit this message, another 'easter egg' which I found is that teamcity for some weird reason does not log ##teamcity[buildnumber service messages in its build log, so it took me already a fair amount of time to figure out how the buildnumber was even being changed at all
The FullSemVer variable is calculated in SemanticVersion.cs#L275, and uses the SemanticVersionBuildMetaData class to get it's build information.

I didn't spend a lot of time reading into how that class gets its build metadata, but I'm pretty sure it uses only git information, and no inputs from any build system (as one would expect).

Something that might be of use to you, I've created a pull-request to the Teamcity meta-runner power pack repository (JetBrains/meta-runner-power-pack#132), this contains a GitVersion4-WithBuildCounter.xml meta runner which will use the json output instead of the buildserver output of GitVersion, then a piece of powershell script will loop through all the json values and log them as teamcity service messages, before eventually logging the buildnumber change service message, in this buildnumber message, it includes the parameter for the teamcity build counter (%build.counter%) after the SemVer variable returned by GitVersion, which results in the build number becoming <SemVer>+build<buildcounter>

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.