JEP proposal: Removing user-facing scripting features from core

61 views
Skip to first unread message

Daniel Beck

unread,
Nov 13, 2017, 6:25:11 AM11/13/17
to Jenkins Developers
Hi everyone,

This is a pre-JEP check[1]: Would https://github.com/jenkinsci/jenkins/pull/3006 (the goal, rationale etc., not the implementation details) have a chance as a JEP, or is it a waste of time?

Thanks,
Daniel

1: https://github.com/jenkinsci/jep/tree/master/jep/1#discussion

R. Tyler Croy

unread,
Nov 13, 2017, 11:41:03 AM11/13/17
to jenkin...@googlegroups.com
(replies inline)

On Mon, 13 Nov 2017, Daniel Beck wrote:

> Hi everyone,
>
> This is a pre-JEP check[1]: Would https://github.com/jenkinsci/jenkins/pull/3006 (the goal, rationale etc., not the implementation details) have a chance as a JEP, or is it a waste of time?


What impact does this have on the Script Console or the CLI, both of which
expose scripting functionality?

I might not be educated enough to understand the nuance of "removing scripting"
which somehow still leaves Groovy in core, and features like init.groovy.d/.
Can you elaborate a bit more on what features/functionalities are being
proposed for extraction here?


Cheers
- R. Tyler Croy

------------------------------------------------------
Code: <https://github.com/rtyler>
Chatter: <https://twitter.com/agentdero>
xmpp: rty...@jabber.org

% gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
------------------------------------------------------
signature.asc

Daniel Beck

unread,
Nov 13, 2017, 11:52:06 AM11/13/17
to jenkin...@googlegroups.com

> On 13. Nov 2017, at 17:40, R. Tyler Croy <ty...@monkeypox.org> wrote:
>
> What impact does this have on the Script Console or the CLI, both of which
> expose scripting functionality?

The "Script Console" and groovy/groovysh CLI commands (and more) would be moved into a plugin, so OOTB, Jenkins would have no text fields taking 'system' Groovy for management purposes.

The idea is that with that plugin, the exact same features will be available, but without it, you don't have them. Implementation TBD.

Oleg Nenashev

unread,
Nov 13, 2017, 2:21:43 PM11/13/17
to Jenkins Developers
Personally I am +1 about **considering** it. My main concern is that Groovy logic is being often [mis]used by configuration management tools, e.g. to install plugins by CLI calls. If we remove CLI handlers from the core, I would expect it to cause some collateral damage on this scenarios. IMHO it needs a wider poll via Users mailing list and blog post once CI is accepted as a draft.

Regarding keeping Groovy in the core, we need a pluggable core components story (JENKINS-41196) to be delivered for that. Groovy Init Hooks are critical to Jenkins environments, and this part should not be detached to plugins IMHO.

BR, Oleg


понедельник, 13 ноября 2017 г., 17:52:06 UTC+1 пользователь Daniel Beck написал:

Jesse Glick

unread,
Nov 13, 2017, 2:30:24 PM11/13/17
to Jenkins Dev
On Mon, Nov 13, 2017 at 6:25 AM, Daniel Beck <m...@beckweb.net> wrote:
> Would https://github.com/jenkinsci/jenkins/pull/3006 (the goal, rationale etc., not the implementation details) have a chance as a JEP

Yes.

Kohsuke Kawaguchi

unread,
Nov 13, 2017, 11:35:03 PM11/13/17
to jenkin...@googlegroups.com
Is this any different from all the other extractions of features into plugins? I guess back then we used to bundle those extracted stuff as bundled plugins?

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0gbewh3Zs%2BMDPZ9C7KBz%3DbE%2BvP_YES51zU5siv6EMp%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
Kohsuke Kawaguchi

Jesse Glick

unread,
Nov 14, 2017, 3:45:29 PM11/14/17
to Jenkins Dev
On Mon, Nov 13, 2017 at 11:34 PM, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:
> Is this any different from all the other extractions of features into
> plugins? I guess back then we used to bundle those extracted stuff as
> bundled plugins?

We now bundle them in `jenkins.war` as _detached_ plugins, meaning
they are not automatically installed—only if there is some implicit
dependency on them from another plugin, or (IIRC) when you are
upgrading from prior to the split point.

The JEP should clarify the status of the split plugin w.r.t. the setup
wizard for new installations: should it be “suggested” but not
“recommended”, say?
Reply all
Reply to author
Forward
0 new messages