Back in TFS 2013 you could temporarily hardcode a build number and then switch back to auto increment to skip ahead with build numbers. Now with TFS 2015 vNext, it seems like I can no longer do this. I went to make a new build definition and wanted to carry on from the last build number from my XAML build but it wouldn't move up.
Any ideas or workarounds for this?
It's also supported. Please check this link for detail steps:Generate custom build numbers in TFS Build vNext
update
Unfortunately, it's impossible.$(Rev:.rr) Its start by one.
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
Related
I'm new to the TFS Build and I'm wondering if I can include in my manual build only those change sets which are not later than date such-n-such.
The general task I'm trying to solve is to build a past release which I did a frozen on date, say, March 1st and omit a recent changes. No branching I do with my project.
Maybe there is a better way to do that?
Thanks.
You can do it when you queue the build.
There is no changeset date concept in TFS expect the creation date of changesets on the same day. Usually we queue a build from a specific changeset in TFS.
You can achieve it by specify the changeset info in Source Version of queue build dialog such as C8 which will build changeset 8. More detail explanation please see below screeshot.
Note: This function is released with TFS2015 update2 for vNext build. To use it, you have to upgrade to Update2 or above.
You could also build a label, how to create take a look at: Use labels to take a snapshot of your files
Can we demonstrate where the release number increase and stays in sequence when we use TFS (example 1, 1.1, 1.2, 1.3, etc) and that when we do a build in Visual Studio the number in TFS will skip ahead by 1 (example – TFS build 1, 1.1, 1.2, build in Visual Studio, then do another build in TFS – the next number in TFS would be 1.4). This is for TFS 2015.
If you want to change the default increase mechanism in build number format. Unfortunately, it's impossible.$(Rev:.rr) Its start by one.
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
If you just want to override your Build number with variables, follow below steps:
Create a Powershell script like this:
$FinalVersion=Some-Function-To-Calculate-Version
$BuildDefName = $Env:BUILD_DEFINITIONNAME
Write-Host "##vso[build.updatebuildnumber]$($BuildDefName)-$($FinalVersion)"
In your vNext build definition, for "Build number format" you could set
it to anything, cause the Build Number will be
overwritten.
In the same vNext build definition steps, add the first step as a
Powershell step, and set your script from step 1 to be executed.
You can later customize if you want to pass variables in order to
calculate your build number.
Queue your build .
This is using the logging commands to set the build number.
The New TFS Build System (vNext) does not come with a versioning function "out-of-the-box" so, to supply that, there are tutorials such as this one:
http://incyclesoftware.com/2015/06/vnext-build-awesomeness-managing-version-numbers/
Where you can see that Microsoft actually supports this with an example Azure Script: https://msdn.microsoft.com/en-us/library/vs/alm/build/scripts/index
So far so good. However, by following those exact steps, my build number now has the REV value stuck at 1. That is, no matter how many builds I do in a row, they all have the "01" stuck at the end.
If I remove the specific "Build Number Format" command (Edit Build Definition > General > Build Number Format), that is:
$(BuildDefinitionName)_$(MajorVersion).$(MinorVersion).$(Year:yy)$(DayOfYear)$(Rev:.rr)
it does increment the version but with the default numbering that TFS2015 uses for builds.
As far as I understood, the REV value increments automatically, so much that there is no possible way of changing it, as we can see in this SO Question: TFS 2015 vNext force build number
So, my question is as follows: is there a parameter that is not listed or missing somewhere that actually prevents the Rev value from increasing? Maybe is there a problem on my installation?
Please note that this happens within the same day, so the rest of the build name does not change in order to justify it remaining at "01".
Thanks in advance for any help or advice.
There is a known issue with VSTS and TFS 2015 where the revision counter doesn't increase when certain special characters are part of the name of the build definition. E.g. [].
You must make sure all the value of your build name except the rev:.rr are all the same.
If nothing else in the build number has changed, the rev integer value is incremented by one. Otherwise, the rev value won't change. So please double check the name of your builds, if the rev value have "01" stuck at the end and nothing else changed with the other values of the build number, it's impossible. If it exists, please add the screenshot, this maybe a bug.
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 have a Build Definition to build a solution on my TFS.
This works well, but it always builds the latest version.
How can I force to build a specific changeset from the past?
How can I use/pass this number to the "MSBuild Arguments" to use it there for deployment?
When you queue up the build from Team Explorer, in the Parameters tab one of the Advanced arguments is get version.
Note: I think you need to specify this in the form C123 where 123 is the changeset number.
The answer to your first question is clearly what #Dylan has stated.
To your second part:
The important argument is GetVersion.
Navigate to activity "Run MSBuild for Project" within your Build Process Template, by default this has a value CommandLineArguments equal to
String.Format("/p:SkipInvalidConfigurations=true {0}", MSBuildArguments)
You can change it to something like
String.Format("/p:SkipInvalidConfigurations=true {0} /p:DeployIisAppPath=/changeset/{1}", MSBuildArguments, GetVersion)
and get where you need to go.
If you use the changeset number, then it will only make sense for CI builds, since they typically build a single changeset.
For any other kind of build, I recommend using the build ID, which is unique, and covers the case of a build that builds multiple changesets.