Commit to my project is triggering external Jenkins Pipeline that does plenty of checks and a release after submit. All projects have a custom label No-Release known by the pipline (set to 0 from default) and submitting with no release needs additional action - checking the checkbox.
What I want to do is to disable release by default on this project. How to set defaultValue of a custom label to +1?
Label from my config (this label appears as a checkbox, not radio):
[label "No-Release"]
function = NoBlock
value = 0 Enable release of jar
value = +1 Skip release of jar
defaultValue = +1
With above configuration the label does not have any value after commit and I still have to manually click the checkbox and post it.
In projects that have set defaultValue = 0 there is also no info appearing after commit.
Does it mean that the defaultValue is being read somehow during submit and the default +1 will be taken by Gerrit but it just doesn't mark the label on review? If so, what to do if I exceptionally want to release, since the checkbox doesn't appear checked?
I'm not sure I've understood your question.
First of all, remember that a label created with "function = NoBlock" is purely informational and its value isn't considered when determining whether a change is submittable or not.
The "defaultValue" is not used automatically after the push to Gerrit, when a default value is defined, that value will just get set in the Reply dialog by default.
See more info about Gerrit labels here.
Related
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.
By default jenkins displaying last 30 builds on the build history view pane. We can trace older builds by clicking More link available at end of the pane. Is there a way to change the list count from default 30? Is it also possible to change this limit per job basis. please suggest approach to get it done if it is not configurable thing.
=Srinivas
You can configure it to a different amount than 30, but only when you start Jenkins and the configuration is for all jobs.
take a look at hudson.widgets.HistoryWidget class in Jenkins core, there you would find the following property:
private static final int THRESHOLD = Integer.getInteger(HistoryWidget.class.getName()+".threshold",30);
that threshold determines how many builds would appear in the history widget.
the property takes its value from a system property or uses the default 30. it is also final, so it cannot change after the first assignment.
so for example, you can start jenkins with -Dhudson.widgets.HistoryWidget.threshold=10 and then you'll have only 10 builds in the history widget.
I have a file with a list of cases that i would like to be able to use as multiple selection check box in my Jenkins project.
example: jenkins.properties
case01_successful_Connection
case02_successful_Disconnection
case03_unsuccessful_Connection
...
The list of cases (in the file) can be from time to time get bigger or smaller!
So, how can Jenkins now read those cases and create during "Build with parameters" the needed check boxes so that the user can select or not the cases?
How should the properties file look like?
Which plug-in should i use to achieve this?
Use the Extended Choice Parameter plugin
Setup new parameter, let's call it mychoice
Select "Type" as Checkboxes
Choose a "Delimeter", for example ,
Under "Choose Source for Value", select Property File
Specify location of property file, it has to be an absolute location, not relative.
Specify "Property Key" that's in the property file, for example "mychoice_values"
Type the following in your property file:
mychoice_values=choice1,choice2,choice3
Every time "Build with parameters" is invoked, it will read that property file, find line that starts with mychoice_values, and will present 3 checkboxes called choice1, choice2, and choice3.
If the property file changes, new choices will be presented
With the answer from Slav and my additional settings I managed to solve my question:
In addition:
1. i added "Default Value" = None
2. i added in the property file: mychoice_values=choice1,choice2,choice3,None (None)
With the above settings 4 check boxes are created and by default the None check box is pre-selected!
It is not perfect the solution, because the user has to uncheck the None box if he checks other boxes! Prefect would be, if None check box would be unchecked automatically when other check boxes are selected!!!
Using gerrit 2.9. I am new to gerrit configuration and am trying to add a Verified label to the All-projects project so that the verified label is shown in the reviews for all projects. The relevant part of the project.config looks like this:
[label "Code-Review"]
function = MaxWithBlock
copyMinScore = true
value = -2 This shall not be merged
value = -1 I would prefer this is not merged as is
value = 0 No score
value = +1 Looks good to me, but someone else must approve
value = +2 Looks good to me, approved
[label "Verified"]
value = -1 Fails
value = 0 No score
value = +1 Verified
I run the following commands:
$ git commit -am "Add verified label"
$ git push -f origin meta/config:meta/config
Now, when I go and try to review a change-set, I see the needs verified line, but I don't see anywhere that I can place it. The screen looks like this:
There is no way for me to set verified on the review.
I had help from this question: Can't find 'Label Verified' permission in gerrit 2.7 but this did not solve the problem.
The problem is that you don't have sufficient permissions to set the Verified label. In Gerrit, all change scoring must be explicitly allowed. If you don't have permissions to set a label, it won't even appear in the Publish view.
To grant users permission to set the Verified label, locate the project you want to affect (or, perhaps more likely, the special All Projects project to have it apply everywhere). On the Access tab, choose Edit. Under refs/heads/*, add a "Label Verified" permission and assign a suitable group. If there's no refs/heads/* reference in the list, add it.
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.