I'm trying make a parameterized build of a new job from my existing job as follows:
I tried both ways:
build('NEXT-DEPLOY-JOB', PARAM_FROM_BUILD:'1.4', DEPLOYMENT_ENVIRONMENT: "QA")
and without paranthesis way:
build 'NEXT-DEPLOY-JOB', PARAM_FROM_BUILD:'1.4', DEPLOYMENT_ENVIRONMENT: "QA"
However in both cases I receive such error:
java.lang.IllegalArgumentException: Expected named arguments but got [{PARAM_FROM_BUILD=1.4, DEPLOYMENT_ENVIRONMENT=QA4}, NEXT-DEPLOY-JOB]
Please tell me, what I am doing wrong here?
The syntax quoted by #Jayan will work, but is deprecated. (And the Workflow syntax has nothing to do with persistence of state.)
Use Snippet Generator to see an example of the right syntax, tailored to the parameter types expected by the particular downstream job you are triggering.
Try something like below( as I learnt from #Jesse Glick, it is deprecated..)
build job: 'NEXT-DEPLOY-JOB', parameters: [new hudson.model.StringParameterValue('PARAM_FROM_BUILD', '1.4'),
hudson.model.StringParameterValue('DEPLOYMENT_ENVIRONMENT', 'QA')
]
Related
I want to pass a custom variable from Job A to Job B. I have tried achieving this using the "Parameterized Trigger" plugin but I didnt work for me.
I am doing it the following way:
On Job A:
execute shell --> export VAR=1
echo $VAR --> is returning 1
Trigger parameterized build on other projects:
PARAM=${VAR}
On JobB:
I have selected this project is parameterized and declared a variable as PARAM. But when I do execute shell --> echo ${PARAM} it returns be ${VAR} instead of 1.
Am I missing anything here ? Any pointers please ? Thanks in advance!!
That's due to the lifetime of VAR is limited within the Execute shell step. If you want variable cross step, even cross from Build to Post Action, you can output the variable to a file in Key = Value pattern, then read it back in Parameterized Trigger
I found a neat way to pass custom variables to downstream job here:
https://sathishpk.wordpress.com/2016/03/01/how-to-passget-parameters-from-shell-command-into-jenkins-other-places/
It worked for me!!
I am trying to configure Jenkins Build Parameter "users" ,to be passed as input to JMETER (v5.1) --> No.Of Threads using the function:${__javaScript(Math.round(${XX}))}
While executing test i am getting following error
error : caused by jdk.nashorn.internal.runtime.ParserException::1:12 Expected but found { Math.round(${__jexl())}
Use a variable to store Math.round(${. Test it with println. Then Invoke ${__javaScript(myVariable)}. Nested ${} is a bad idea, groovy interprets them.
as M Navneet Krishna said, your question is a bit succinct for us to provide better answer. But I gave you a method that should help you debug your stuff
I want to add a new mandatory job property to capture the some custom fields in the jenkins job. I searched in the plugins list but couldn't find any relevant plugin that solves the issue. Is there any plugin to solve this ? (Note: Extra columns plugin doesn't solve my usecase)
A freestyle job can be configured to build with parameters. See: https://wiki.jenkins.io/display/JENKINS/Parameterized+Build
You can configure the parameter type (string, boolean, drop down etc), give a description of the parameter and a default value. The string parameters can include validation rules:
https://wiki.jenkins.io/display/JENKINS/Validating+String+Parameter+Plugin
Though this only warns when the current parameter value does not meet the regex validation rule, it doesn't prevent the build from being submitted. If submitted in this state, however, the build will fail.
From a quick google, it appears this doesn't work for pipeline jobs, See the last comment on the plugin page url above from Miguelángel Fernández:
If you look at the implementation of class ValidatingStringParameterValue you'll see that it overrides the implementation of public BuildWrapper createBuildWrapper(AbstractBuild build) in a way that aborts if the string is invalid. This will only work on Freestyle jobs and other job types extending AbstractBuild. I'm afraid this does not apply to pipeline jobs. Maybe in your prior project you used freestyle jobs.
An alternative for freestyle jobs is to do in job validation before initiating any build steps using the 'Prepare an environment for the run' from:
https://wiki.jenkins.io/display/JENKINS/EnvInject+Plugin
You would need to write groovy to check the parameters submitted and abort the build at this point if the values aren't suitable. Something like:
def validateString = binding.variables.get('testParam')
if (!binding.variables.get('testParam').matches('\\d+')) {
println "failure of parameter validation - does not match regex"
throw new InterruptedException()
} else {
println "Validation passed carry on with build"
}
This doesn't work on pipeline builds - as the plugin is quote:
'This plugin has some known limitations. For Example, Pipeline Plugin is not fully supported.'.
But if you are using scripted pipelines you can implement something similar:
stage 'start up'
if(!env.testParam.matches('\\d+')) {
error 'failure of parameter validation - does not match regex'
}
Often when looking at scripted jenkins pipeline code, I see this pattern...
step([$class: 'GitHubSetCommitStatusBuilder',
statusMessage: [content: 'Pipeline Started']])
I have not had any luck finding documentation on this technique and would love it if someone could explain what this is doing and when/why it is useful. I believe this is a way to instantiate and populate the members of an underlying groovy class - but more detail would be appreciated.
Also is this documented anywhere?
Here is a reference that briefly explains the syntax. Basically, you are providing the step() function a map of arguments in the form of name-value pairs. The first argument which is especially denoted by the name $class tells the function which class (plugin) to instantiate.
It also seems that this syntax is being deprecated in favor of shorter syntax, also explained in the same link.
I am also struggling with this syntax, but unfortunately have not found any doc yet.
I guess this syntax is used to doing the instance initialization.
All step classes implement interface BuildStep. After script loaded, all step instances initiated, then their perform method are invoked during build procedure.
All above is my conjecture.
There's also another quick reference from "Pipeline: Basic Steps" github repo documentation :
https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/master/CORE-STEPS.md
Syntax
As an example, you can write a Pipeline script:
node {
sh 'make something'
step([$class: 'ArtifactArchiver', artifacts: 'something'])
}
Here we are running the standard Archive the artifacts post-build action (hudson.tasks.ArtifactArchiver), and configuring the Files to archive property (artifacts) to archive our file something produced in an earlier step. The easiest way to see what class and field names to use is to use the Snippet Generator feature in the Pipeline configuration page.
See the compatibility list for the list of currently supported steps.
Simplified syntax
Build steps and post-build actions in Jenkins core as of 2.2, and in some plugins according to their individual changelogs, have defined symbols which allow for a more concise syntax. Snippet Generator will offer this when available. For example, the above script may also be written:
node {
sh 'make something'
archiveArtifacts 'something'
}
NB: The Simplified syntax, makes reference to Plugin Steps parameters
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.