Jenkins Extended Choice Parameter Plugin Groovy Script - groovy

So in the website for the plugin, the change-log for Version 0.61 (Mar 30, 2016) mentions that they have exposed Jenkins and project bindings for use in a groovy script. I'm currently trying to set a parameter (multi select) and i want it to have different options based on the value of another parameter which is set before this one in the Jenkins job. However i'm not able to get the value of that other parameter in the script.
My problem is very similar to the one explained here
I've tried using ${param}, $(param), $param, bindings.variables.get('param') in the script, and none of it works
I've also tried to set that parameter in the Variable bindings section of the script but still no success.
Any ideas about the correct way to obtain the value?

I set the variable binding as param on the other field that you want to dynamically populate and used param (please note that i didnt use $ ${} or binding.get etc). It worked for me.
As a side note, Will active choice reactive parameter work in your case?

Related

Declarative Pipeline using env var as choice parameter value

Disclaimer: I can achieve the behavior I’m looking for with Active Choices plugin, BUT I really want this to work in a Jenkinsfile and controlled with scm because it’s tedious to configure the Active Choices on each job we may need them on. And with it being separate from the Jenkinsfile creation, it’s then one job defined in multiple places. :(
I am looking to verify if this is possible, because I can’t get the syntax right, if it is possible. And I haven’t been able to find any examples online:
pipeline {
environment {
ARTIFACTS = lib.myfunc() // this works well
}
parameters {
choice(name: "Artifacts", choices: ARTIFACTS) // I can’t get this to work
}
}
I cannot use the function inline in the declaration of the parameter. The errors were clear about that, but it seems as though I should be able to do what I’ve written out above.
I am not home, so I do not have the exceptions handy, but I will add them soon. They did not seem very helpful while I was working on this yesterday.
What have I tried?
I’ve tried having the the function return a List Because it requires a list according to the docs, and I’ve also tried (illogically) returning a String in the precise syntax of a list of strings. (It was hacky, like return "['" + artifacts.join("', '") + "']" to look like ['artifact1.zip', 'artifact2.zip']
I also tried things like "$ARTIFACTS" and ${ARTIFACTS} in desperation.
the list of choices has to be supplied as String containing new line characters (\n): choices: 'TESTING\nSTAGING\nPRODUCTION'
I was tipped off by this article:
https://st-g.de/2016/12/parametrized-jenkins-pipelines
Related to a bug:
https://issues.jenkins.io/plugins/servlet/mobile#issue/JENKINS-40358
:shrug:
First, we need to understand that Jenkins starts running your pipeline code by presenting you with Parameters page. Once you've set up the parameters, and pressed Build, then a node is allocated, variables are set, and your code starts to run.
But in your pipeline, as presented above, you want to run some code to prepare the parameters.
This is not how Jenkins usually works. It's definitely not doing the following: allocating a node, setting the variables, running some of your code until parameters clause is reached, stopping all that, presenting you with GUI, and then continuing where it left off. Again, it's not how Jenkins works.
This is why, when writing a new pipeline, your first option to build it is Build and not Build with Parameters. Jenkins hasn't run your code yet; it doesn't have any idea if there are any parameters. When running for the first time, it will remember the parameters (and any choices, if were) as were configured for this (first) run, so in the second run you will see the parameters as configured in the first run. (Generally, in run number n you will see the result of configuration in run number n-1.)
There are a number of ways to overcome this.
If having a "somewhat recent" (and not "current and absolutely up-to-date") situation fits you, your code may need minor changes to work — second time. (I don't know what exactly lib.myfunc() returns but if it's a choice of Development/Staging/Production this might be good enough.)
If having a "somewhat recent" situation is an absolute no-no (e.g. your lib.myfunc() returns the list of git branches, and "list of branches as of yesterday" is unacceptable), then your only solution is ActiveChoice. ActiveChoice allows you to run some code before showing you the Build with Parameters GUI (with script approval etc.).

Setting variables from Mule 4 Script (Groovy)

Previously in Mule 3.x.x, we would be able to set variables from within a groovy script using. message.setInvocationProperty("name", "value").
I cannot seem find a way to do this anymore. I am aware that the mule message structure has changed, but is there a way for one to set variables/attributes from a Mule 4 script similar to the way we could in Mule 3?
Thanks in advance.
No, in Mule 4 you cannot modify vars directly.
You can set the return value of the script to go directly to a variable though using the target attribute, with it's value being the name of the variable:
<scripting:execute engine="groovy" target="myVar">
Probably best as well - to keep the script decoupled from mule specifics.

Can we merge JAVA_OPTS variables through recipe in chef?

I have installed Java through some cookbook and have set some default variables, now I want to add some more variables (Application specific) through my cookbook. How can I do that through Recipes in Chef. I tried to pass some variables in setenv.sh but it is overriding the default values instead I want to merge the variables and override existing variable values.
My code in setenv.sh:
export JAVA_OPTS="$JAVA_OPTS -Xmx2048m"
where $JAVA_OPTS - default variables
First way to do it would be to update the attribute defining the bases values in your application cookbook, as the attributes are read before the recipes are evaluated your file would end up with the correct values.
You're not saying with which cookbook you're using so I'll base the example on the tomcat cookbook
This cookbook define an attribute default['tomcat']['java_options'] = '-Xmx128M -Djava.awt.headless=true'
The easiest way it to complement this by using something like
default['tomcat']['java_options'] = "#{default['tomcat']['java_options']} -Xmx2048m"
The obvious problem is that you end up with 2 -Xmx values, usually the JVM will take the latest but it become hard to find what options is at which value when there's a lot of overwriting.
Second option is to take advantage of jvmargs cookbook wich gives helpers functions to deine the java options and use in your setenv.sh template at end.

Can I use Groovy scripts in SoapUI to enable/disable assertions?

I'm using SoapUI Pro and a DataSource/DataSink loop to test a web service.
To make life more fun, I need to pull from four distinct source files, all of which will cause different expected results.
I'd really like to do this in a single test loop, because having scripts with multiple loops tends to crash SoapUI more often than not, but the sticking point is assertions.
How can I enable or disable assertions in a Groovy script in SoapUI? GetData doesn't give me anything to hook onto, and a documentation dive did not reveal the proper syntax. I'd assume something like testCase.assertion, but there's no such property as "assertion" on testCase.
Alternately, can I use a Groovy script to change the assertion's content? In other words, if I want phrase X with file 1, phrase Y with file 2, I'm just as happy using the same assertion, so long as I can change the content it's trying to match.
You could use your Groovy script to set some kind of property testCase.setPropertyValue('expected', 'value'), based on which file you are reading. You could then use property expansion ${testCase#expected#} in the assertion content.

On a build of a Jenkins job, is it possible to change build parameters midway through?

We are using Jenkins to automate several of our build and test processes. For some of our process, the engineer starting the build needs to specify a parameter. But the range of possible and optimal values for that parameter change throughout the course of the day.
What I would like to do is let the engineer specify a value - if they know an optimal value - or leave it blank and have a value be calculated by an early build step. If the value is calculated, I would like the calculating build step to update the parameter value of the job. That way, all subsequent build steps don't have to worry about using the parameter or calculating it, they just use the parameter regardless.
It looks like the Groovy Script Plugin might be able to do this, but I can't see how I can SET the build parameters, just GET them.
Found the answer: use the EnvInject Plugin. One of the features is a build step that allows you to "inject" parameters into the build job from a settings file. I used one build step to create the settings file, then another build step to inject the new values. Then, all subsequent build steps and post-build operations used the new value.
Update with an example:
To add a new parameter (REPORT_FILE), based on existing one (JOB_NAME), inject a map with new or modified parameters in the Groovy Script box:
// Setting a map for new build parameters
def paramsMap = [:]
// Set REPORT_FILE based on JOB_NAME
def filename = JOB_NAME.replace(' ','_') + ".html"
paramsMap.put("REPORT_FILE", filename)
// Add or modify other parameters...
return paramsMap
Jenkins does have the ability to parameterize builds. For a string parameter, the developer can leave the field blank and then your build scripts can check to see if the env. variable for the parameter is set. If the env. var. is not set, the script can perform whatever calculation is needed (I don't think Jenkins has "pre-build steps") and pass it along. For a choice parameter the first line can be something like (Default), and again the build script can test its value and act accordingly.
Note on (Default)
I tried leaving the first line of the choice box blank, and Jenkins saved it correctly the first time; but when I came back to reconfigure the build Jenkins ran some kind of trim on options and the leading blank line was removed so I settled on (Default).
I hope this helps,
Zachary

Resources