OK
I have a Jenkins job (Jenkins version more recent).
In my Jenkins job, I have couple of parameters (string type).
Ex: param1=value1 ... to paramN=valueN
Now, in Jenkins job, under BUILD section, I'm calling "Invoke Gradle".
In this Gradle section, I'm calling a task(s). For ex: clean build
What I need is: I want to pass the above Jenkins job's parameters to Gradle as -PparamN=ValueN way?
But when I'm passing -Pparam1=${param1} -Pparam2=${param2} ...and so on in "Switches" option in Gradle Build section, I see Jenkins log is showing:
It called Gradle exectuable successfully with the parameters.
...somepath.../bin/gradle -Dparam1=value1 -Dparam2=value2 ... -DparamN=valueN -Pparam1=value1 -Pparam2=value2 ... -PparamN=valueN
This tell, Jenkins is kind enough to pass the parameters(which I have defined in the job) to Gradle as "-D" way for free.
My ?s:
Well, I don't want to pass the above parameters as -Dxxx=yyy
I want to pass the parameters only -Pxxx=yyy way
Is this possible with using "Invoke Gradle" plugin?
I guess at this time, there is no way to tell Gradle plugin in Jenkins to NOT pass the parameters (defined in Jenkins job) as -Dxxx=$yyy way (which it's doing for us for free).
We can though, use "switches" box/option to specify these parameters as -P way but it's little confusing how -D parameters will impact the JVM which Gradle uses to run itself and whether -D parameters will somehow clash with -P parameters (as they are getting passed / defined twice).
As a workaround, I stopped using Gradle plugin and used "Execute Shell" option under BUILD section and called gradle executable with the respective parameters (-P way) and task(s).
This is just a plain way of calling Gradle with parameters and tasks like what you'd run at CMD or $ prompt.
As with the Jenkins Gradle plugin 1.27 there is a checkbox to tell the plugin not to pass parameters as system properties and add some parameters manually.
You can also select to pass all parameters as Gradle properties what would be what you probably want.
Let Jenkins have the parameter as -D first. And then you can pass to Gradle with -P. For example, if you have a parameter called env, you can put it in the task as
-Penv=${env}
Related
So I have build my own custom resourse type. As, suggested in this link.
I want to know how to test this docker image? How would I get the docker running?
What would be the command? Would I have to pass additional build parameters?
Is there a particular way custom resource types are tested?
Please provide me all the information.
(thanks in advance)
Most concourse resources get tested like this- you write some test that run the binary, with json piped in over stdin, and then you check the return code and the output.
You can run those tests standalone, or run them as a part of the build process- so just docker build . to re-test.
After running gui tests on Jenkins I am getting java.awt.HeadlessException on build Jenkins:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
I am using xvfb in pipeline Jenkins (script), eclipse & maven.
How coud I solve this issue via Jenkins file (script) or maven pom or in another way?
Why am I getting this exception?
Somewhere in your pipeline you probably need to have export DISPLAY=:0.0 or something similar.
We use the NUnit console to run our tests in Jenkins and we have many projects that share some tests. We want to be able to run the tests concurrently and to do that we need the tests to look at different databases.
I would like to pass in the project name to the nunit-agent which wouldn't know how to use it, but we would be able to fetch that from the command line arguments running the test and decide which database to look at.
I am open to suggestions.
We currently use "C:\Program Files (x86)\NUnit.org\nunit-console\nunit3-console.exe" Path\Tests.dll --result=nunit-result1.xml to run the tests
nunit-agent uses arguments to pass information that NUnit needs. For passing information to the test, the standard way is to use the --params command-line option and then access the values from your tests by means of TestContext.Parameters.
I have Buildbot set up on a Windows 7 machine that's set to run a series of tests when I check in python code to a git repo. When I check on the build details via the web interface it displays a set of build steps that have been run as defined in my master.cfg configuration file.
Currently I have several shell command steps that each run a windows .bat file. Each of these steps is sequentially titled "shell", "shell_1", "shell_2", etc. Is there a way to re-name these steps (i.e. "format_check", "unittest", etc.)? I don't see an option to name build steps in the "build steps" section of the buildbot documentation.
Generally you just add it as a parameter in the call to addStep: e.g. name="step_name"
Updating the referenced documentation's examples to include a name parameter:
f.addSteps([
steps.SVN(repourl="http://svn.example.org/Trunk/", name="svn"),
steps.ShellCommand(command=["make", "all"], name="make"),
steps.ShellCommand(command=["make", "test"], name="test")
Please note, although my specific example here involves Java/Grails, it really applies to any type of task available in Bamboo.
I have a task that is a part of a Bamboo build where I run a Java/Grails app like so:
grails run-app -Dgrails.env=<ENV>
Where "<ENV>" can be one of several values (dev, prod, staging, etc.). It would be nice to "parameterize" the plan so that, sometimes, it runs like so:
grails run-app -Dgrails.env=dev
And other times, it runs like so:
grails run-app -Dgrails.env=staging
etc. Is this possible, if so, how? And does the REST API allow me to specify parameter info so I can kick off different-parameterized builds using cURL or wget?
This seems to be a work around but I believe it can help resolve your issue. Atlassian has a free plugin call Bamboo Inject Variables Plugin. Basically, with this plugin, you can create an "Inject Bamboo Variables from file" task to read a variable from a file.
So the idea here is to have your script set the variable to a specific file then kick off the build; the build itself will read that variable from the file and use it in the grails task.
UPDATE
After a search, I found that you can use REST API to change plan variables (NOT global). This would make your task simpler: just define a plan variable (in Plan Configuration -> tab Variables) then change it every time you need to. The information on how to change is available at Bamboo Knowledge Base