Setting job parameters in JobDSL description

[Vassilis Rizopoulos]

Hi all.

Is there a way to set build variables (notice: build variables, not environment variables) in a JobDSL definition so that they are accessible in PipelineDSL scripts just like the job parameters?

Basically all my jobs look like this with some variations on triggering, log and concurrency handling:

pipelineJob("FOO")
{
  description('')
  concurrentBuild(true);
  logRotator {
    daysToKeep(1)
  }
  throttleConcurrentBuilds {
    maxPerNode(1)
  }
  parameters {
    stringParam('X','FOO','BAR')
    stringParam('Y','FOO','BAR')
  }
  definition {
    cps {
      script(readFileFromWorkspace('pipelines/foo.groovy'))
    }
  }
}

Now I have the main job that can be scheduled by hand and configured in all the ways that matter and then I want specific instances of that pipeline to run for example nightly - so I have a fixed set of parameter values for those jobs.

So I want a way to say X='FOO', access X in the pipeline script and not have it appear in the GUI as a setable parameter.

Thanks for the help,
V.-

[Fiouz]

Try setting the env-inject plugin and use env.X / env.Y from your pipeline.

https://jenkinsci.github.io/job-dsl-plugin/#path/pipelineJob-environmentVariables

--
You received this message because you are subscribed to the Google Groups "job-dsl-plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to job-dsl-plugi...@googlegroups.com.
To post to this group, send email to job-dsl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/job-dsl-plugin/1e6038cc-9cee-4026-bcf8-0e7fad2480b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
Fiouz

[Vassilis Rizopoulos]

That is the solution I have been avoiding.

There are two reasons for this: I like build variables better than environment variables and to pass environment variables will necessitate changing existing pipeline definitions (also re-arrange code between jobDSL and PipelineDSL files etc.)

The second reason is that envInject leaks memory like a sieve. FOund out the hard way and unfortunately have no memory dumps to help with debugging cause...deadline. Meaning I verified it and then deactivated immediately and let the system continue work. 

Any chance of a more palatable workaround?

Cheers,
V.-

[le...@vicarious.com]

Hi Vassilis,

Did you find a more palatable workaround for this? I'm in a similar situation I think.

L