I'm working on a custom Build Workflow and need to set the LastGoodBuild at the definition (MSDN Description of BuildDefinitionDetail).
Any Ideas how to set the LastGood Build (Not with an update statement in the database :-))
Related
I have to customize TFS DefaultTemplate.xaml with MSBuildArguments Parameter.
Once we try to create new XAML build definition & select default template, once it gets loaded then I want to set code MSBuildArguments in Advance setting & parameter should be /p:DebugType=pdbOnly;Configuration=Release by default.
As of now this Arguments we have to put manually whenever we create a new build definition. I want to make it customize this template.
screen shot:
Specify MSBuild Arguments when create a build definition or queue a build is more convenient.
However if you want to bind the arguments with the xaml build template, then you need to custom the template.
In your scenario, you can simply replace the value of CommandLineArguments with below strings: (Note that the arguments you added here will be hidden, that means you can not see them in build definition, they are set to be the default arguments)
String.Format("/p:SkipInvalidConfigurations=true {0}", "/p:DebugType=pdbOnly;Configuration=Release").
But same time the MSBuildArguments you specified in build definition will not be available any more.
You can reference below articles to custom the build template to replace the MSBuildArguments:
Pass Relative Path Arguments to MSBuild in TFS2010 Team Build
Properly incorporate MsBuild arguments into your build process
template
I have a TFS 2017 build that was setup with multi-Configuration that has a multiplier of BuildConfiguration. This worked fine with until I took all the build steps and moved them into a Task Group. Now I get an error that seems to indicate that it's looking at the full string of the variable BuildConfiguration dev,int verses iterating over it. Does this not work with Task Groups?
Based on my test, Multi-Configuration is not available for Task Group.
When you select all the build steps and create a TaskGroup, you need to set Multi values (eg : Release,Debug) for the buildConfiguration.
But during the build it will meet this error message :"Error MSB4126: The specified solution configuration "Release,debug|Any CPU" is invalid"
To correct that error, you need to set it as unique value (eg :Release ) or leave it as empty. Thus the build works, but actually it's not the real Multi-Configuration build even though it displays Release and Debug there. (You can check the build log for the "Multi" builds, you will see the actual msbuild command with argument )
I have submitted a feedback here for this issue, hope achieve it in future.
I figured out how to make it work.
My problem was the BuildConfiguration variable that gets created in the Task Group has to be set to refer back to the BuildConfiguration variable at the Build level (may be using the wrong term here...).
So instead of setting the Task Group var to dev,int I had to set it to $(BuildConfiguration) which refers it back.
So my task group variables look like this (I highlighted the BuildConfiguration var that was my issue):
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.
Is it possible to nest TFS build template arguments in one another?
Example (Set via build definition ui):
$(ToolsRoot) = E:\BuildTools
$(MSPECTools) = $(ToolsRoot)\MSpec\
Alternatively, is it possible to use environmental variables.
I have tried both, and neither seemed to work.
I need to find a way of setting the build root dynamically, as it differs on our various build servers.
I suppose you have implemented a topology like the this:
So, you need to control the root for each Agent.If you open the TFS Admin Console > Build configuration in Build Machine #1 you 'll see the Build Controller & Agents A.1 & A.2.If you open TFS Admin Console > Build configuration in Build Machine #2 you 'll see Agents A.3, A.4, A.5 & A.6.
For any given build Agent, if you click on "Properties" you 'll see the "Working Directory" entry, which typically is set to something like $(SystemDrive)\Builds\$(BuildAgentId)\. On runtime this is transformed into something like C:\Builds\55.
For any given build, in the build definition area "Workspaces" this "Working Directory" equals the entry $(SourceDir).
Suppose you have set in Agent A.1 a working directory "C:\A.1\Build" & in Agent A.2 "C:\A.2\Build". In order to get what you need, you have to set in the build definition a mapping to $(SourceDir)\Template
For my Team Build process, I have created Work Flow activities that control deployment. I want to choose at runtime whether to deploy the build.
So, I need to send Deploy=true or false as an input to the work flow runtime initiation.
I can do this by defining a Work Flow custom metadata value with an internal argument. I can then set the Deploy value at runtime via the Queue Build dialog under the Parameters tabs.
My question is: How do I specify my custom variable when starting a TFS build from the command line with tfsbuild.exe start?
The command line parameter is called /msBuildArguments
TfsBuild start teamProjectCollectionUrl teamProject definitionName
[/dropLocation:dropLocation] [/getOption:getOption]
[/priority:priority] [/customGetVersion:versionSpec]
[/requestedFor:userName] [/msBuildArguments:args] [/queue]
[/shelveset:name [/checkin]] [/silent]
You can use: tfsbuild start http://yourserver:8080/tfs/ YourProject YourBuild Definition /msBuildArguments:"Deploy=true"