Importing class definitions into script

[Eberhard Beilharz]

It seems that with version 1.60 it's no longer possible to import other files into a script. The workaround (importing the classes from a JAR file as described in https://github.com/jenkinsci/job-dsl-plugin/wiki/Real-World-Examples#import-other-files-ie-with-class-definitions-into-your-script) also doesn't work anymore, and the Additional classpath option got removed in 1.60.

How can I now share code between multiple scripts? Or do I miss something?

Thanks,
    Eberhard

[Victor Martinez]

Hi there,

1.60 version has been released to fix some security issues. You can find further details:

https://groups.google.com/forum/m/#!topic/job-dsl-plugin/lYgX3boW0Pk

https://groups.google.com/forum/m/#!topic/job-dsl-plugin/t3QNtnxqNno

Cheers

[Eberhard Beilharz]

Yes, I know about the security issues and the new 1.60 version. Unfortunately that version breaks things for me - which forces me to downgrade to 1.58 so that I can run my scripts.

I haven't tried if the problem got introduced in 1.60 or in 1.59, but it definitely didn't exist in 1.58.

[Daniel Spilker]

It's not a problem, it's a feature that has been introduced in 1.60. Importing code into DSL scripts not possible if script security is enabled. And script security is enabled by default. See https://github.com/jenkinsci/job-dsl-plugin/wiki/Migration#migrating-to-160 for details.

Daniel

On Tue, Apr 11, 2017 at 7:05 PM, Eberhard Beilharz <e...@sil.org> wrote:

Yes, I know about the security issues and the new 1.60 version. Unfortunately that version breaks things for me - which forces me to downgrade to 1.58 so that I can run my scripts.

I haven't tried if the problem got introduced in 1.60 or in 1.59, but it definitely didn't exist in 1.58.

--
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-plugin+unsubscribe@googlegroups.com.
To post to this group, send email to job-dsl-plugin@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/job-dsl-plugin/86e44f74-3daf-4361-8a01-2aa6714be5ab%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Eberhard Beilharz]

I guess calling it a feature is an option :-)

I read the migration page before I did the upgrade. Now that I know the details I can see that it talks that importing code is no longer possible. For someone who only occasionally deals with Jenkins/Job DSL/Groovy however it could be worded more clearly. Maybe it would be possible to explicitly mention in the migration doc that importing code is no longer possible.

And it would be good to update https://github.com/jenkinsci/job-dsl-plugin/wiki/Real-World-Examples#import-other-files-ie-with-class-definitions-into-your-script - this has still the old information.

Thanks,
    Eberhard

You received this message because you are subscribed to a topic in the Google Groups "job-dsl-plugin" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/job-dsl-plugin/pJQkPx0fuA8/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAKqW32CFv8J1x1N2CFxLH4_Ews2vvrv28uPVOuufBXQVTnTdPg%40mail.gmail.com.

[Marcin Grzejszczak]

Yeah so my question is basically the same. What can we do now about this? The whole idea of Jenkins Job DSL was to generate jobs from code. If that's no longer the case this plugin is kind of useless cause I need to create the whole code inside the DSL script. The migration page also provides no proper information on how to really migrate. I wouldn't call "migration", a process where it's basically said that a backward incompatible change is done and quite a lot of projects will blow up. 

Do I understand this correctly that I need to disable the script security? That's the only option?

W dniu środa, 12 kwietnia 2017 11:13:24 UTC+2 użytkownik Eberhard Beilharz napisał:

I guess calling it a feature is an option :-)

I read the migration page before I did the upgrade. Now that I know the details I can see that it talks that importing code is no longer possible. For someone who only occasionally deals with Jenkins/Job DSL/Groovy however it could be worded more clearly. Maybe it would be possible to explicitly mention in the migration doc that importing code is no longer possible.

And it would be good to update https://github.com/jenkinsci/job-dsl-plugin/wiki/Real-World-Examples#import-other-files-ie-with-class-definitions-into-your-script - this has still the old information.

Thanks,
    Eberhard

Daniel Spilker <m...@daniel-spilker.com> wrote on 2017-04-11 at 20:44 +0200:

It's not a problem, it's a feature that has been introduced in 1.60. Importing code into DSL scripts not possible if script security is enabled. And script security is enabled by default. See https://github.com/jenkinsci/job-dsl-plugin/wiki/Migration#migrating-to-160 for details.

Daniel

On Tue, Apr 11, 2017 at 7:05 PM, Eberhard Beilharz <e...@sil.org> wrote:

Yes, I know about the security issues and the new 1.60 version. Unfortunately that version breaks things for me - which forces me to downgrade to 1.58 so that I can run my scripts.

I haven't tried if the problem got introduced in 1.60 or in 1.59, but it definitely didn't exist in 1.58.

--
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/86e44f74-3daf-4361-8a01-2aa6714be5ab%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Victor Martinez]

It's not about the plugins but the security advisor policy:

- https://jenkins.io/security/

- https://jenkins.io/blog/2017/04/10/security-advisory/

Therefore, backward compatibility is something you can keep as long as you disable the script security:

- https://wiki.jenkins-ci.org/display/JENKINS/Permissive+Script+Security+Plugin

- https://issues.jenkins-ci.org/browse/JENKINS-32681

Finally, if the migration process is not clear, please contribute to the Migration.MD in case there are details which are missing or not clarified. I'm pretty sure others will take advantage of this.

Cheers

[Jakub Bocheński]

I was also confused by the change, even though I read the migration guide (and the advisory) before. Only after reading it carefully now I noticed this will break.

What confused me were the multiple possibilities with sandbox/script approval/Authorize project plugin. I expected that when running the build as an admin user I could still import classes.

I'd love to improve the documentation but I don't feel like I have a good enough understanding of the setup.

[Edmund Haselwanter]

I read through the thread, the documentation as well as the migration page. And yes, it still is unclear to me on how to 'share' code between dsl scripts.

from the pages:

---

To avoid loading arbitrary code from the workspace without approval, the script directory is not added to the classpath and additional classpath entries are not supported when security is enabled. Thus importing classes from the workspace is not possible and the "Additional Classpath" option is not available.

---

ok. so how to do it? is the only way c&p code around? the other option I see is to actually create a jar in the class path of jenkins itself and update that ?outside? of jenkins?

and I think it would be wise to remove the power move sections about using libraries, cause those won't work.

am I missing something super obvious?

[Sumit Agarwal]

We are having the same problem and do not want to be c&p the code which we have abstracted a lot.

Is the solution to release the classes that we import/change less often as extensions to the DSL plugin (if this is possible) and create a pipeline for making that an easy process. I am not sure if updating jenkins to use a new version of extensions will ever be as easy as just updating code in git.

Any other thoughts on how this could be addressed in a secure and efficient manner.

[as...@cloudera.com]

If your Jenkins running under company's network or you do not care about security and still like to have security enabled to use AD/LDAP for authentication and advantages of all new fixes under job-dsl plugin then following might work.

Return false on this line https://github.com/jenkinsci/job-dsl-plugin/blob/master/job-dsl-plugin/src/main/groovy/javaposse/jobdsl/plugin/DescriptorImpl.java#L130

This will still allow you to have security enabled and have "additional classpath" option available under "Process Job DSLs". Though downside is to maintain your own copy for maintenance but seems like a good workaround. I tested this on 1.65 latest plugin and seems to work.