I am using TFS 2012 and the OOTB default build template. I have a build definition that uses the default Build Number Format of:
$(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)
For some reason, the revision number generated by TFS is really, really large. For example the last build was PrintOps-Main_20140626.124829.
Only one of my other builds definitions produces builds with such a high revision number. That other build is CI build of this same solution. This leads me to believe that there is something in a project file that is overriding the TFS build number with some custom logic. But I don't know if that is even possible. All other build definitions' revision numbers start out at 1 and increment the revision number by 1 if a build is ran multiple times a day. These build definitions also increment by 1, but they start out at 1248xx.
As troubleshooting I have tried different process templates and modified the Build number format. Everything works as expected except the $(Rev:.r) portion. As soon as I introduce the revision portion back into the build format, I get a very large number.
Is my suspicion correct that it must be some sort of override in a project file? If so, any suggestions on what to look for? There are several (15+) projects in this solution so any advice is appreciated.
I retried the build on a different day and pulled out individual sections of the build number format ($BuildDefinitionName,$Date,$rev) to test each piece individually. I don't know if it was because the new builds were occuring on a different day or if using just $(Rev:.r) with nothing else in the build number format reset things, but I finally got the build number to come out correctly.
Related
We have a process we worked out with our XAML builds that used the TFS change set number in the name of the individual builds. We are trying to convert some of these builds to the new build system on TFS 2015 and running into issues getting change set into the build name.
If we use $(Build.SourceVersion)$(Rev:.r) in the Build Number Format field of the build definition, we get an output of C12345.1 on a triggered build, but then .1 on a manually queued build. We would expect to see C12345.2. Lots of research boils down to, $(Build.SourceVersion) has to be manually entered when the build is queued in order for it to be populated when the Build Number is calculated.
Ok, so we dropped into PowerShell to try to manipulate the build numbers. Once in the PowerShell task, Build.SourceVersion is populated with the correct value. We tried having the Build Number Format of the definition just be $(rev:r), which allowed us to get it in PowerShell, combined it with the Source Version value, and using the result to update the build number via the logging command Write-Host "##vso[build.updatebuildnumber]"$buildVersion. This gives us an output of 12345.1 on both the triggered and manual builds, but rev:r never increments, since there are no builds matching the pattern found in the Build Number Format at the time it is calculated. So manually queuing the builds ends up with any number of them that have the exact same name.
Does anyone have a recipe for getting a build name that reliably contains the Source Version and Revision values where everything increments correctly for both triggered and manual builds?
No, It's not able to do this. You need to understand the token $(Rev:.r) first:
What is $(Rev:.rr)?
To ensure that every completed build has a unique name. When a build
is completed, if nothing else in the build number has changed, the Rev
integer value is incremented by one.
Source:MSDN
In your scenario you set the build number format as $(Build.SourceVersion)$(Rev:.r), if the value of $(Build.SourceVersion)changed, then the value of $(Rev:.r) will not be incremented, it will always keep "1". Only the value of $(Build.SourceVersion) keep the same, then $(Rev:.r) will be incremented.
Besides, based on my test, the variable $(Build.SourceVersion) in build number format is only available when builds were triggered automatically on commit/checkin (on Continuous integration). It can not be resolved when you queue build manually and keep the Source Version field as empty (by default it will get the latest version). So, if you queue build manually, then you need to specify the specific Source Version (e.g C458) in the queue build dialog.
However if you want to set the builds name as incremental ones, you can update the build number manually with the REST API:
PATCH http://server:8080/tfs/Collection/Project/_apis/build/builds/{buildId}?api-version=2.0
Content-Type: application/json
{
"buildNumber": "TEST.20170123.1"
}
So after much research and trial & error this is the closest we managed to come to our desired output...
The Build number format is set to $(Build.SourceVersion).$(Build.BuildId) in the configuration.
We use a powershell script to parse the Assembly File, Source Version, and Build Id to come up with a full 4 part version number in the form of Major.Minor.ChangeSet.BuildId.
We push this new version number back to our build number using Write-Host "##vso[build.updatebuildnumber]"$buildNumber
We also used the Assembly Info step to push this calculated version number back to the actual build process, so that the DLLs come out with the same version number as the build.
This gets us a version number that is unique for each build, and points back to specific a particular state of the source, which was the priority. What we lose is the nicely incrementing build numbers that reset with each change. Instead we have a number that increments for every build that occurs anywhere in the system, and never resets.
Is there a way of formatting the revision in a Build Number Format to always be three digits long starting from 1000?
I have $(Rev:.r) which adds .1 and .2 to concurrent builds.
I want this to be .1001
This is TFS 2013.
I have tried .1rrr and get the exception
Exception Message: Unable to expand the macro $(Rev:.1rrr) specified
in build number format
Use the following:
$(Rev:.1rrr)
(Tested on VS Online)
The caveat here is that this won't rollover to 2000 if you are doing more than 999 builds in a day.
This might work on TFS2013. It does not work on TFS2015.
Hard code your Build Number Format.
1.0.0.100
Perform a build. Change the Build Number Format back.
1.0.0$(Rev:.r)
The build might pick up from the hardcoded build number.
This appears to work for TFS2010 according to this SO answer. Worth a shot in TFS2013!
We have our projects configured with MSBuild script customization to modify the ApplicationVersion property in the project and copy that into the AssemblyInfo.cs file when the project builds. The problem is that we have TFS set up to run on a nightly schedule, with "Build even if nothing has changed since the previous build" unchecked. But since TFS itself is producing this version update, it will rebuild and increment every night. So this is sort of an infinite loop of our own design, but trying to figure out how to get out of it.
If the "changed since the previous build" detection is based on the history timestamp, ideally it'd be nice if when the version gets updated and commits to TFS it does it with a timestamp that precedes the build time. Is that even possible?
If the "changed since the previous build" detection is based on some boolean/bit flag, is there a way to reset it?
Using TFS 2012.
I'm assuming that you're checking in the new version of the assemblyinfo.cs once it's been updated, and this is why TFS is queuing a new build. Have you tried adding a comment to the checkin of ***NO_CI*** This will definitely suppress a CI build but I'm not 100% certain if it will work in your scenario.
Another option is generating the version number via an algorithm rather then just incrementing a counter and checking it back in to Version Control. This circumvents the issue of a new build being triggered
i.e if your version number looks something like
1.2.3.4
Where 1 is Major (modified by a human not the build process)
2 is minor (also modified by a human)
the final 2 digits are then updated by an automated process.
You could use number of days since January 2000 for digit 3 (an arbitrary number but something that would change on a daily basis) and either the latest changeset number in Version Control or the total number of builds performed by TFS for digit 4.
This would fulfill 2 requirements, that version numbers are unique for a given build of an assembly, they always go up.
I would suggest that you don't check the new version number into TFS. There is no value in having the version number in there.
I typically set the checked in assembly info numbers to all zeros. ( 0.0.0.0) and never update them except locally for the build.
This gives you the benefit of always being able to identify locally built DLLs.
I know that the AssemblyInfo class can be set to auto increment the build number as such:
[assembly: AssemblyVersion("1.0.*")]
But this works only for building the app myself (i.e. from the IDE). I use TFS to build my solution (multiple projects). The assemblies in the build drop location are all still set to version 1.0.0.0.
What is the path of least resistance for getting the build or revision number into the AssemblyVersion?
Ideally, TFS already has a $(BuildID), an auto-incrementing integer, that I use as my Build Number Format for defining my drop location...can't that just become the version build number in the AssemblyVersion and AssemblyFileVersion?
Well, gave up on native TFS. This was the closest to a configuration-only solution (no coding). The documentation on this site shows clearly how to modify your TFS server and build to use this dll to get an incrementing number in your assembly's product and file build and rev (it's a Julian date and rev).
http://tfsversioning.codeplex.com/
I think creating your own custom build activity to update the version number is the easiest way to achieve this. Here is a good post on that:
http://www.ewaldhofman.nl/post/2010/05/13/Customize-Team-Build-2010-e28093-Part-5-Increase-AssemblyVersion.aspx
I'm currently looking at a TFS build server setup & I was trying to set up a process whereby I can set up a build template to build to a folder based on the version number of a .NET assembly that's part of the build (As per the assemblyinfo.cs file). I've got it building to the standard looking folder ("Release_20130502.1"), but that's not exactly useful in 4 months time when we want to find the build for the v1.1.0 release.
Basically I want to make a special build template which will create a major release, and I'd like the folders it makes to be more noticable as versions rather than timestamps. I'm also hoping to automatically label the release as that version too. I know how to copy the files & make labels, but I'm not sure how to get at the version numbers.
I'd also love if I could get this into the Build Name recorded in TFS somehow but I suspect that might be a bit optimistic.
Does anyone have any idea how to do this (Or alternatively any other technique that'll get me easily recognizable release version builds)?
Take a look at build number format property for build definitions this is used to generate the build number and in turn the build folder during build and label in sourcecontrol if its enabled, you can modify this manualy to pass desired build number. The mentioned drop folder can be manually given as well. And you can always copy the folder after build by hand.
You can use revision variable to create something that works similiar to what you want, Revision number gets incremented if there is build with same name in system
Format: Release v1.$(Rev).0 - this would give you Release v1.1.0, Release v1.2.0, ... on each build
You will have to customize build definition with custom activity for your defined goal to work without manual interaction. However with details you have provided this approach has issues - each project has its own assembly info - which one do you use, what if they are different? This should get you started.
http://www.ewaldhofman.nl/post/2010/04/20/Customize-Team-Build-2010-e28093-Part-1-Introduction.aspx
You can take a look at these may find something useful
http://tfsbuildextensions.codeplex.com/
It all comes down how often do these build take place, if its week or more then doing it by hand is perfecly valid aproach in my book.