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.
Related
I'd like to be able to trigger a build in TFS Build when a developer tags in Subversion. I'd also like to use the tag number as part of the build and release name. Is this possible in TFS right now?
There is no this built-in trigger for building a repository type of subversion in TFS.
You could first get the event (a developer create a tag in svn) from SVN. Not sure how to do this in SVN, should be something like the service hooks in TFS. Then trigger a build in TFS 2017 using REST API. How to do this please refer: How to trigger a build in TFS 2015 using REST API
As for how to use the tag number as part of the build and release name, see below:
Create custom build number during build
With Team Build you can update the build number at any time during the
build by outputing "##vso[build.updatebuildnumber]1.2.3.4" to the log
during the build.
You can see the full list of logging commands here https://github.com/Microsoft/vso-agent-tasks/blob/master/docs/authoring/commands.md
This will update the build number & name.
The down side that you have run into is that you can no longer use the
auto-incrementing number that you have been trying to use. You need to
come up with the version number yourself, and then pass it back using
the output above.
Source
Add two more related blogs:
vNext Build Awesomeness – Managing Version Numbers
Generate custom build numbers in TFS Build vNext
We use a nice $(date:yyyy.MM.dd)$(rev:.r) build number format in our day-to-day agile sprints. However, the release must be numbered with a simpler 1.0.0.rev schema.
Ideally, I would like to give the build number as a variable, which would be automatically expanded in the "queue build" dialog, where it would be possible to be overriden. How can it be done?
I tried moving the $(date:yyyy.MM.dd)$(rev:.r) format to a variable, and use that variable in the general tab, and got error 400.
You could directly use Environment variables such as Build.BuildNumber /BUILD_BUILDNUMBER
Using this just equals to the name of the completed build. You can specify the build number format that generates this value on the General tab.
If you just want to generate custom build numbers like 1.0.0.rev schema in TFS Build vNext. You can take a look at below blogs:
Generate custom build numbers in TFS Build vNext
Managing vNext build Version Numbers
This is very simple.
1) Just create a Powershell script like this
$FinalVersion=Some-Function-To-Calculate-Version
$BuildDefName = $Env:BUILD_DEFINITIONNAME
Write-Host "##vso[build.updatebuildnumber]$($BuildDefName)-$($FinalVersion)"
2) In your vNext build definition, for "Build number format" just set it to anything. It doesn't matter because the Build Number will be overwritten.
3) 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.
4) Queue your build and see the results.
In Team City, there is the concept of a build counter. The counter is incremented each time a build is performed and is scoped to a single build definition - so invoking build definition A will not update the counter for build definition B and vice-versa.
In Visual Studio Team Services (was Visual Studio Online) build, there is a $Env:BUILD_BUILDNUMBER but this number seems to be scoped globally to all build definitions.
In order to label my builds and the subsequent nuget packages using the semver major.minor.patch I would like access to a teamcity like build counter, scoped to a single build definition.
I'd rather not use a script to update some file or http based per build store, which feels like a lot of work for something which is so simple out of the box in Team City.
You can update "Build number format" under "General" tab in your build definition settings to use "$(Rev:.r)" as the build number like following:
major.minor$(Rev:.r)
Use $(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.
If you want to show prefix zeros in the number, you can add additional
r characters. For example, specify $(rev:.rr) if you want the Rev
number to begin with 01, 02, and so on.
Refer to this link for details: Build Number Format.
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
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.