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.
Related
How could I check passed job parameters before the job start building.
Based on the result of applied conditions for passed parameters, if result is True, I will start the build, if result is False, then skip the job without even start the build and then abort it or make it as Failure/Unstable.
Note, I know I can do that inside the job itself in Jenkinsfile, by check the passed parameters there. But I would like to do that in way so that I don't need to start build job directly.
I think what I'm looking for is such as Pre-Build procedure.
If Pre-Build == True:
-> Start Build Else
-> Skip the build at all
Is there a plugin or a workaround can help in that please ?
Thanks.
Nope. Parameters are part of a job. A ”valid paramter" parameter can only be determined in the context of a job. The only thing that would know what is a valid is the logic inside the job. Therefore bthe job must be triggered to do the evaluation.
You could create a generic trigger job which took your parameters, did some universal validation and the triggered the actual job, passing validated parameters in.
But what would you achieve by that? There are many extended build parameters plugins (including choice parameter) which only let the user pick from available options.
I have a Jenkins job A and Promotion job configured in A.
I am passing certain parameters in promotion job and build-number of Parent job A is one among them.
If I pass ${BUILD_ID} in the shell part of promotion job, it takes the promotion job build number.
ie, I have a job A - build #1 and promotion job B #2, I am passing $BUILD_ID and value 2 is getting passed instead of value 1.
The ID of the job being promoted can be obtained using the environment variable - PROMOTED_ID. For additional information and other environment variables, please see the doc
I got it solved using one of the environment variables.
PROMOTED_ID did the magic !!!
When I run a manual build, I'd often like to mark it with documentation to show why I ran it. Is this feature available with a plugin?
thank you!
I would approach this by adding a build parameter as a string, as above, then use the Description Setter Plugin to set it from that parameter. We use something like this for the regex:
^\++ : BUILD DESCRIPTION : GERRIT_CHANGE_OWNER_EMAIL=([^#\s]*)\S*, BUILD_USER_EMAIL=([^#\s]*)\S*, GERRIT_BRANCH=(\S*), GIT_COMMIT=(\S{8}).*$
and this for the description:
\1\2, \4, \3
As a result we get:
jspain, 0ee3198b, master
or when it fails, we get:
Failed due to timeout.
wayvad, fc7bdf2a, master
this "Failed..." text comes from the Build Timeout Plugin
I am not aware of a plugin that can do this, and after a brief search I could not find one to do what you describe.
You can mimic this behavior by adding a string parameter in the job that takes a default value of automatically started when it's normally run, but that you can change to my reasons for this build when starting it manually.
You could then use a batch (or groovy or ) build step to print the contents of that parameter into the build log. If you do some sort of SCM checkout I'm not sure how close you can get it to print to the line that contains the username that started the job, however you can click on the view parameters button in the job build and see what was in the field quickly without having to parse the logs.
The downside of this is that parameter would have to be added to each job.
With DSL I can do something like:
bnumber = build.environment.get("BUILD_NUMBER")
build("Compile.Net", BUILD_NUMBER: bnumber)
which is great. It seems to set the BUILD_NUMBER var of the downstream job. However the display name is still with the incremented automatically number and also if I manually start the job after, it will have incremented build number from the wrong one (not the one that has been passed as a parameter). I guess there is another action needed as a shell script or something to set the BUILD_NUMBER and Displayname and save it incremented in the configuration as nextBuildNumber file. Perhaps this PlugIn could help:
https://wiki.jenkins-ci.org/display/JENKINS/Next+Build+Number+Plugin
The question is if there is a better way of doing it or I should continue to work in the same direction? Is there a better way of setting the build number of a downstream job to be the same as the build flow job?
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.