TFS Online - start $(Rev.r) from 0 - tfs

I am using $(Rev:.r) in my build number.
Major.Minor$(Rev:.r)
This works perfect and increments on every build and gets reset if the the major or minor version gets changed.
But the numbering starts at 1 and not 0. So the first build is not 1.0.0 but 1.0.1 which is not really what I am going for.
So is there a way to make the Revision start at 0?
Thanks for the help...
P.S. Unfortunately it is not possible to use Git and GitVersion in this project.

No, this can't be achieved.
What is the Rev?
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.
Source Link: Build number format
Moreover, anytime you change your Build Number in a TFS build, the revision resets to 1. It' by default, you could not change this value. Since if you could be able to set the value start from 0, it's also should be able to set it start from 100. This will mess up the build number.

This might be old thread but I have found a solution that worked for me.
I have variables for MinorVersion and MajorVersion. Then created my own Revision variable called RevisionVersion and made a counter expression like that:
$[counter(format('{0}.{1}',variables['MajorVersion'],variables['MinorVersion']), 0)]
And now build number can be set as
$(MajorVersion).$(MinorVersion).$(RevisionVersion)
If MajorVersion or MinorVersion changes RevisionVersion is reset to 0. This gives 1.1.0 build number format and with every new build Revision part is increased by 1.

As a workaround to reset the revision number, you could create a clone of the existing build definition and kick off a new build with the recently created definition. This will initiate a new build starting at revision # 1.
Here is how to clone the build definition, click on the 3 dots next to the definition title under Build definitions page. Refer the screenshot below;
Click here to view screenshot - clone a definition
As like 1.0.0.1 if you have set the format to be 1.0.0$(rev:.r) in the build format field.
Otherwise resetting the revision # within a build definition isn't possible. I have tried deleting earlier builds and also tried manually setting the build number to 1.0.0.0 to reset but nothing worked.

Here's how I do it.
I use branch name to set the version number. I create a branch called release/1.2.3 to create a release 1.2.3. I suppose one could use variables.
Hence my trigger will be on the release/* branch
I will then create a counter from the branch name which will be reset every time I change the branch name.
variables:
buildCounter: $[counter(variables['build.sourceBranchName'], 0)]
And, finally, I'll use this in the name after the variables block.
name: $(build.sourceBranchName).$(buildCounter)

Related

How to conditionally trigger a build in Jenkins

I have a couple of jobs both would trigger on Monday but 1 st project on 1st Monday and 2nd project on 2nd Monday. I couldn't use the Jenkins cron to trigger the project based on condition
because cron can be used to trigger a project on a specific time of the day or week of the day alone (eg 0 6 ** 1 to trigger project on Monday morning 6 AM) and not based on condition.
I am looking for a solution where I could use the cron to trigger the project but it would have some condition only if it passes the project would be triggered.
Currently jenkins cron doesn't support triggering project based on condition.
You can do this in two ways
i)The simplest way is to create two projects, one for running in even week and other for odd week.
ii)Once the project is triggered you write a condition either using windows batch command or shell script to check if the current week is as expected (Odd/Even) if it meet the condition you proceed the next step or fail it.
But the issue with this solution is you will have a unnecessary project.
i)A bit hard but stable way is have a Parent Project and two dependent(child) project - i.e one for even and other for odd
ii)In the parent project execute a shell/windows batch command to check if the current week is odd or even refer - Date convert to week number based on it you create a variable and set value as true or false and then write the values into a property file
iii)Then convert the value as a environment variable using Jenkins Environment Injector Plugin (url - https://plugins.jenkins.io/envinject/) for details on how to convert refer - How to set environment variables in Jenkins?, Now you can access the value across the project
iv)Create a new conditional build step (Plugin url - https://plugins.jenkins.io/conditional-buildstep/ )
In that trigger your child project based on comparison of environment variable with a expected condition (i.e if "TRUE" then trigger Odd week project)
You can trigger the build, check the condition, and bail out of the build if the condition does not hold. You can optionally fail the build in this case.

Build number of previous build number

I am trying to create a Jenkins pipeline job which will check the status of previous before it trigger the execution. But I am not able to find the url to previous build number. I tried constructing url using BUILD_NUMBER-1 option but not working because BUILD_NUMBER is not a integer. Could someone help me to find the url to previous build ?
You can make use of the currentBuild global variable. You can see all global variables at http://jenkins-url/pipeline-syntax/globals.
The number can be retrieved from it. You can see all of the whitelisted calls on RunWrapper.
number
build number (integer)
So, in your pipeline you could do currentBuild.number.
If there is a previous build, you could also use previousBuild and use currentBuild.previousBuild.number. Keep in mind that previousBuild can be null.

How to start vNext TFS 2015 build revision at a specific number

I am using the vNext build system of TFS 2015.
I currently have the my builds versioning in the traditional format. Major.Minor-rev.RevisionNumber. So, if I have a build for Major 1, Minor 12, the build version would look like 1.12-rev.1 when I start. I would like to know if it is possible to have the build version start at a number other than one, say 55. Such that the build version would look like 1.12-rev.55, and then increment by one as usual after that.
Actually, it is possible to effect this in a vNext build without hacking the database.
There are 2 steps.
First, you will need to implement a powershell build step (as the first step of the build) with the following inline script:
#Set the BuildNumberOffset. (Change this to the difference between the TFS build number,
#and the number that your build needs.)
$BuildNumberOffset = 543
#Don't change
$BuildNumberParts = $($env:BUILD_BUILDNUMBER) -split '\.'
$TFSRevision = [int]$BuildNumberParts[$BuildNumberParts.Length-1]
$BuildNumberParts[$BuildNumberParts.Length-1] = ($TFSRevision + $BuildNumberOffset).ToString()
$BuildNumber = [string]::Join(".", $BuildNumberParts)
Write-Host "##vso[build.updatebuildnumber]$BuildNumber"
Second, on the Label format field of the repository tab set the label format to "$(Build.BuildNumber)" instead of "$(Build.DefinitionName)$(rev:.r)". This is important so that your label will be the same as your updated build number.
There is a way to do this. It isn't pretty, but it works.
Assuming you have a build number format of something like $(Major).$(Minor)-rev$(rev:.r)
To do this queue up a build which will get the number 1.12-rev.1. Then go to the TFS database and into a table called tbl_Build. Find that last build you did and change the value in the BuildNumberRevision column to 54.
The next build that fires off will now be 1.12-rev.55
Unfortunately, it's impossible.
Every build definition has a build number format field where you can use some macros to dictate what the resulting build number should look like. In this format we are using $(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
Moreover, if you want to generating a custom build number without increment.
Here is a blog with detailed procedures:Generate custom build numbers in TFS Build vNext
Couldn't we just manually set this in the format for one build i.e:
$(Major).$(Minor)-rev$(rev:.54)
and then afterwards revert back to:
$(Major).$(Minor)-rev$(rev:.r)
Not tried it, but if it works it'll save hacking around in the database.
You can do this easily, but only if you are using a Git repository in conjunction with a tool called GitVersion
It is a wonderful tool that I always use with my git repos. For your use-case: When you have version 1.2.3 and you want to jump to version 1.2.55, you just add a git tag 'v1.2.55' and it will start the versioning from there. GitVersion is a lot more complicated and does a lot more, but that is one of the features. You don't have to mess with special PowerShell scripts or anything, it instead reads your git repo history and git tags overrides the calculated versioning. There is already a TFS/VSTS/Azure Devops extension called GitVersion that works great from the same developer.
The Answer of #Steve Sims works still with TFS 2017 vNext. Thanks a lot!
I had only to do the first step "to add the script as an inline powershell script in my build." Thanks to #PainElemental
With this "Build number format" in the Options-Tab it works:
$(BuildDefinitionName)_1.2.0$(rev:.r)
I didn't label my sources with the build, so I don't checked:
Second, on the Label format field of the repository tab set the label
format to "$(Build.BuildNumber)" instead of
"$(Build.DefinitionName)$(rev:.r)". This is important so that your
label will be the same as your updated build number.
I think, you can edit the Label Format on the "Advanced" GetSources Options. (usually hidden).
This was also very painful for us, migrating from a existing CI system with it's own build numbering, we needed build numbers to increment from a specific value. Hacking databases wasn't allowed in the organisation, offsets seemed a cludge.
In the end, we used an AutoIt script to start and stop builds and delete the build result using the WebUI and left it running. Not nice, but it did the job.
Needs tweaking for screen resolutions and such, timings also perhaps. Use AutoIt Window Info to find the button locations, make sure browser is fullscreen (not windowed) Run it for a few cycles to ensure it robust before setting the loop larger.
#include <AutoItConstants.au3>
;Increment TFS build count (Chrome browser buttons locations). Start from build result page.
For $i = 1 To 15 Step 1
ConsoleWrite ( "Loop " & $i & " of 5" & #CRLF )
Sleep(200)
MouseClick($MOUSE_CLICK_PRIMARY, 1800, 200, 2)
Sleep(500)
MouseClick($MOUSE_CLICK_PRIMARY, 1150, 881, 2)
Sleep(2000)
MouseClick($MOUSE_CLICK_PRIMARY, 1800, 200, 2)
Sleep(500)
MouseClick($MOUSE_CLICK_PRIMARY, 1055, 165, 2)
Sleep(10000)
Next
TFS/Devops is a really immature CI system, and it's not a patch on what we were running. Unfortunately corporate policy said we move to TFS, as nobody ever got fired for buying Microsoft products (but plenty of people should have got fired for buying them/forcing them where they don't belong).

How do I change the Build number format parameter while queuing a build

I am using Visual Studio Online for Source Control and Build processes. I created a new build definition using the TfvcContinuousDeploymentTemplate.12.xaml. When Queuing a new build from within VS I have the chance to change some parameters, but I can't change the Build number format. What determines what shows up on that parameter list and how can I make sure the Build number format appears there?
My suggestion is to investigate modifying the build template to:
1) Take a custom input value, which I believe you can change on each invocation of the build; and
2) Finding the appropriate step to interrogate the existing Build Number and modify it based on this input.
This should get you started:
http://msdn.microsoft.com/en-us/library/dd647551.aspx
Alternatively, you could remove the Build Number Activity in its entirety and substitute your own – but I don’t think these measures are warranted in this case. This would get you started down that trail:
http://blogs.msdn.com/b/willbar/archive/2010/01/21/generating-custom-build-number-in-tfs-build-2010.aspx
HTH –
jlo
To show the property you have to edit the template, expand the arguments, search for Metadata and click on the ellipse towards the right of the row. Find the property you want, in my case it is BuildNumberFormat and change the View this parameter when: Always show the parameter

How to store last value of parameter in parameterized job as a default value for next build in Jenkins?

I have been using Jenkins for a few weeks and I have one small problem. I can't find any plugin or solution for storing the last value of a parameter in a parametrized job as a default value for the next build.
For example:
My parameter takes build version (1.0.0.01) in the first build. In the next build it will be changed to 1.0.0.02, but I want to have a 1.0.0.01 in the default value field as a hint.
Does anybody have a solution or advice?
The Persistent Parameter Plugin is exactly what you are looking for!
You just need to download it from the official Jenkins repository and install it, no need for any additional setup.
Then on your job, you just need to add a "Persistent Parameter" in order to have default values used and saved between builds.
You can add a System groovy build step to your job (or maybe a post build Groovy step) using the Jenkins API to directly modify the project setting the default parameter value.
Here is some code that may be useful to get you started:
import hudson.model.*
paramsDef = build.getParent().getProperty(ParametersDefinitionProperty.class)
if (paramsDef) {
paramsDef.parameterDefinitions.each{ param ->
if (param.name == 'FOO') {
println("Changing parameter ${param.name} default value was '${param.defaultValue}' to '${param.defaultValue} BAR'")
param.defaultValue = "${param.defaultValue} BAR"
}
}
}
Have a look at the class ParameterDefinition in the Jenkins model.
You probably need to modify the default param value based on the current build executing. Some code to get that would look like this:
def thisBuildParamValue = build.buildVariableResolver.resolve('FOO')
The Extended Choice Parameter plugin provides this capability by using default parameter values from a properties file. A default parameter can be selected from a specified property key and this key can be programmatically modified in your current build. I would then use a groovy script in the current build to set the value of the default property key for the next build.
As an example you would have an Extended Choice Parameter whose default value is defined by a properties file version.properties with keys as follows:
versions=1.0.0.02, 1.0.0.01, 1.0.0.00
default.version=1.0.0.02
The parameter definition would include:
Property File=version.properties
Property Key=versions
Default Property File=version.properties
Default Property Key=default.versions
The GUI for your parameter in the next build would show a selection list with 1.0.0.02 selected by default. This feature is also very useful for pipeline builds where you would want the parameters of a downstream build stage to be set by an earlier build.
The only drawback to this approach might be that the parameter UI will be a drop-down selection. You may opt to have a single value in the versions property key so not to confuse your users.
Similar to thiagolr's answer, but for those of you using pipelines! It appears the persistent-parameter-plugin doesn't work for those using pipeline 2.0. But there is a patched version at https://github.com/ashu16815/persistent-parameter-plugin which seems to work for me.
Clone it locally:
git clone https://github.com/ashu16815/persistent-parameter-plugin.git
Build it:
mvn clean install
Install it in Jenkins:
1) Navigate to Jenkins > Manage Jenkins > Manage Plugins
2) Click Advanced tab
3) Scroll down to Upload Plugin
4) Click Choose file and select the persistent-parameter.hpi in the target directory of the maven build above
Now it should persist.

Resources