TFS Build allows to define a label format in "repository" tab in build definition. I can define custom variables in "variables" tab and use them in label format definition. But is there any possibility to change a value of such custom variable in batch script in custom build step? Or maybe in some other type of a build step? I can get a value of such variable in a batch script, but any changes are ignored (though "Modify Environment" checkbox is set). Is there any possibility to use a value calculated during a build process as a part of a label format?
Thanks in advance!
It should be. There is no much difference with the custom variable in "variables" tab and custom variable in batch script in custom build step.
However, please note not every custom variable can be used as a part of a lable format. Please double check this.
Some build variables might yield a value that is not a valid label.
For example variables such as $(Build.RequestedFor) and
Build.DefinitionName can contain white space. If the value contains
white space, the tag is not created.
Update from OP： As a workaround, with build.updatebuildnumber you could update a build number and then use $(build.buildNumber) in label format.
Related
I'm trying to tag a build using the built-in, tag sources functionality of team foundation server, the tag is created during the build phase and outputted as an output variable. However the label sources step never evaluates the variable and the step fails. Why does the label sources step not evaluate the value of the tag variable ?
Tag sources has been setup like this
The Tag step creates and outputs the tag
Both the "Tag Step Logs" and the "PRINT ENV VARS" show the value of the variable that is created.
The label sources then fails as it's not able to read the tag value from the variable
A solution to the issue has been found.
I am updating the variable Build.BuildNumber and using this in the Tag sources. This is working as this variable is available to the label sources step.
I added the following line, to update the build variable
Write-Host ("##vso[build.updatebuildnumber]$tag")
This updated number is then accessed by the label sources step using the variable
$(Build.BuildNumber)
Thanks Alexey, for figuring this out.
That is because the Output Variable is only available in the next session, that means it only can be read from the steps which behind the step Tag variable creates.
But as you can see, the Label source is in the fist Get sources step, it's before the step Tag variable creates.
So, the Output Variable can not be read. We can not label sources with the customized variable.
We can only use the predefined and user defined variables on the variables tab to Label sources. See Label sources for details.
I'm trying to find jenkins parameter plugins to do;
Editible textbox (multiline)
Set default text from property file (something like groovy script)
Can you please suggest any plugins?
I tried Active chioce parameter plugin, Extended choice parameter plugin. But those are only provide choice option not textarea.
And Dynamic parameter plugin also seems not support multi-line.
Exists a way in jenkis jobs configuration to pass text parameter to execute a job. Adding Text Parameter, you can define a simple text multiline parameter, where users can enter a text value, which you can use during a build, either as an environment variable, or through variable substitution in some other parts of the configuration.
To define parameters for your job select "This build is parameterized", then using the drop-down button to add as many text parameters or other type as you need.
more info look at
Parameterized Build
When I add a new parameter in the Process Parameter Metadata Editor, checkin my changes, and go back to edit the definition or queue a build from it, the parameter is not showing. Here is the parameter in the editor:
Other custom parameters I added in the past show up fine. For example, this one shows up fine:
So..I would expect my new parameter to show up the same way this one works.
I tried closing and re-opening VS2013 (I have update 4) and changing to another build controller, but get same behavior. How do I fix this?
A parameter must be defined at the Build Arguments level (the place you found the Build Parameters Metadata).
Afterwards, the Metadata defines how it shows up, which editors it uses, and what description should be shown on it.
That's about the metadata, but you need to add your parameter in the Arguments tab.
You will find it in the XAML Workflow editor at the bottom three buttons/tabs: Variables, Arguments and Imports.
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
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.