Job-DSL library setup

[Mark Gargan]

Hi folks, 

 

       I'm trying to put together a library of Job-DSL builders that might  be re-used throughout our organisation. With the Additional Classpath field unavailable with the security turned on (Matt Sheehan's job-dsl-examples Readme) could anyone recommend a method that might emulate the Global Shared Pipelines @Library annotation which quite seamlessly incorporates the implementation of a library within an executing pipeline. 

At the moment the only way I can see to accomplish this is perhaps to have a GIT clone step before the job-dsl step runs somehow which pulls the builder code from the library repo directly into the workspace of the referencing project. There are obvious filename clash possiblities if the packaging isn't unique enough but it might work? If anyone has any ideas that would be great!

Packaging the builders into a library and pulling it into the lib directory during a gradle build would work but I would have to still have the Additional Classpath field available. Can't see our Jenkins admin being too happy about turning off the security. 

Thanks,

Mark.

[Jakub Bocheński]

Hi,
 you can find a workaround here: https://groups.google.com/d/msg/job-dsl-plugin/pJQkPx0fuA8/tKMLC4DiAQAJ but it requires forking the plugin

I've asked about this here before: https://groups.google.com/d/msg/job-dsl-plugin/5UJvef-_c00/VaK4sSxSAAAJ
You can find some more details in this ticket (https://issues.jenkins-ci.org/browse/JENKINS-43726

> There are obvious filename clash possiblities if the packaging isn't unique enough but it might work?

AFAIK it won't work but there is a PR to "allow import of Groovy code from the workspace" https://github.com/jenkinsci/job-dsl-plugin/pull/1078

[Mark Gargan]

Thanks very much for the response Jakub! thanks for pointing out that fork option. Unfortunately I'm not the admin on our Jenkins instance and asking them to update the existing job-dsl-plugin with a forked version that works around the script security I wouldn't imagine will be received very well. 

Daspilker's PR seems to allow for the sandbox to allow imports which I think would be all I need but it's taking it's time to be merged? I pull everything in using a shared library. I'm sure I could create a quick copyMe method that'd take a destination directory and copy the groovy files to the root of each of the jobDSL's target directories making them available? That way I wouldn't have to touch the security. I can blow away the workspace each time the job runs to clear it down. I've done this for a python module I had in the resources directory of a library before.