Jenkins 2.0 initial setup plugin selection

950 views
Skip to first unread message

Daniel Beck

unread,
Jan 21, 2016, 1:56:15 PM1/21/16
to Jenkins Developers
Hi everyone,

For Jenkins 2.0, we're aiming for a much better 'getting started' experience, aimed for users new to Jenkins.

We already talked about this last year[1], but the discussion didn't really have a great result, so I'd like to start over by defining a list of guidelines on what kind of plugins qualify for inclusion first. My initial proposal is in the wiki[2]. Please take a look and provide feedback in this thread.

Specific selection of plugins would be the next step.

Daniel

1: https://groups.google.com/forum/#!msg/jenkinsci-dev/w-_18aYn4QQ/t_WT442bBwAJ
2: https://wiki.jenkins-ci.org/display/JENKINS/Plugin+Selection+for+the+Setup+Dialog

ogondza

unread,
Jan 22, 2016, 8:14:30 AM1/22/16
to Jenkins Developers, m...@beckweb.net
How about some criteria for testing? Requiring X% for code coverage is clearly wrong. But how about the plugin needs to have _some_ tests? What I believe we should do is having a CI that verifies the plugin selection against the core version. Not sure we should use ATH or plugin-compat-tester or both.

--
oliver

Daniel Beck

unread,
Feb 23, 2016, 1:08:48 PM2/23/16
to jenkin...@googlegroups.com

On 22.01.2016, at 14:14, ogondza <ogo...@gmail.com> wrote:

> How about some criteria for testing? Requiring X% for code coverage is clearly wrong. But how about the plugin needs to have _some_ tests? What I believe we should do is having a CI that verifies the plugin selection against the core version. Not sure we should use ATH or plugin-compat-tester or both.

Looks like a reasonable requirement. Any idea how we could incorporate that?

Daniel Beck

unread,
Feb 23, 2016, 5:20:18 PM2/23/16
to jenkin...@googlegroups.com
Hi everyone,

I added two additional criteria to the wiki: The plugin shouldn't require a restart to work (otherwise it's not exactly a great getting started experience), and it shouldn't be just a UI/theming plugins that replaces part of the Jenkins UI (as including them in a list of suggested/recommended plugins would just be weird).

Based on these criteria I tried to build a list of plugins to feature in the initial setup wizard.

A reminder: All plugins are still available in the plugin manager. But with 1100+ plugins now, it'd be great if we could provide a curated subset to get new users started. This also means that particularly complex plugins, that require knowledge of Jenkins internals, even though they may be useful, are basically excluded by default.

To approximate popularity, I used the previous install count multiplied by the growth in the previous year (as neither alone is a sufficient indicator of popularity). Then I sorted by this value, and went through the list, being mildly judgmental. This is the result:

https://docs.google.com/spreadsheets/d/1TKziW5oEfX9NYAPrZkz-wXPt5s-zG-znIB5-Jwt3tmw/edit#gid=0

This is the list of plugins I came up with for the initial setup dialog. If a plugin wouldn't be used, the reason is stated. Regarding 'Unsafe': Wearing my security officer hat, I consider every plugin with Groovy scripting that is not using the Groovy Sandbox to be unsafe, even if it implements security measures.

Please review the list, and let me know what you think.
> --
> 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/044ECC6E-4C39-45B6-90E3-1A0C40BD5E9B%40beckweb.net.
> For more options, visit https://groups.google.com/d/optout.
>

Arnaud Héritier

unread,
Feb 23, 2016, 5:39:16 PM2/23/16
to jenkin...@googlegroups.com
#19 
maven-plugin100810126144157844No: We don’t really want people to use this

LOL, even if I agree, all Maven users will install it ....
Evil but highly used :(


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



--
-----
Arnaud Héritier
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

Daniel Beck

unread,
Feb 23, 2016, 5:41:48 PM2/23/16
to jenkin...@googlegroups.com

On 23.02.2016, at 23:38, Arnaud Héritier <aher...@gmail.com> wrote:

> LOL, even if I agree, all Maven users will install it ....
> Evil but highly used :(

The idea is to not steer them towards it. The maven build step in core is functional, and it should be an actual decision to use it.

It's kind of weird that we today bundle a feature with Jenkins that, whenever someone comes to the mailing lists and asks about a problem with it, we call it the 'evil' job type and link to Stephen's blog post on it.

Manfred Moser

unread,
Feb 23, 2016, 6:15:23 PM2/23/16
to Jenkins Developers
At least it will easily be possible to have it NOT available so unknowing users dont get into trouble. I strongly believe that a lot of people only use this because they dont even know about the Maven build step.

Maybe we should change the job type title to include something like "deprecated" or "legacy" or so.

I for one will be glad once its gone. We even have a script we run to find any jobs and alert on it. Then we tell people to change the job ... 

manfred 



Oliver Gondža

unread,
Feb 24, 2016, 2:08:51 AM2/24/16
to jenkin...@googlegroups.com
For the plugin test coverage we can add a requirement to the wiki the
plugin must have test coverage. It should not be a hard criteria but at
least stating that we take testing seriously on default plugin selection
is useful IMO.

Ad ATH, there is a way to provide a list of HPIs to be installed for
every tests executed - that is a great way to make sure installing
recommended plugins is not going to break some other feature in core or
reasonably popular plugin. Perhaps we can go a step further and install
all recommended plugins for all tests by default.

--
oliver

Robert Sandell

unread,
Feb 24, 2016, 5:44:41 AM2/24/16
to jenkin...@googlegroups.com
So what defines UI/Theme plugins?

I see for example that extra-columns and sidebar-link made the cut?

/B

--
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.

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



--
Robert Sandell
Software Engineer
CloudBees Inc.

Robert Sandell

unread,
Feb 24, 2016, 5:47:44 AM2/24/16
to jenkin...@googlegroups.com
... and gravatar.

And I believe docker-commons is just an API plugin.

/B

Victor Martinez

unread,
Feb 24, 2016, 7:05:21 AM2/24/16
to Jenkins Developers
What about docker plugin? It might be a good candidate as part of the plugin selection as it's widely used and might alienate the concept of reproducibility and configuration, which are nowadays quite trendy, with Jenkins.

Mercurial and Perforce are not part of that list, although their usage are not massive compare to Git or SVN, but might be also important to have them as part of the SCM category. That's my point of view and sorry if I said something which it was already said previously.

Cheers

Daniel Beck

unread,
Feb 24, 2016, 7:48:19 AM2/24/16
to jenkin...@googlegroups.com

On 24.02.2016, at 13:05, Victor Martinez <victormar...@gmail.com> wrote:

> And I believe docker-commons is just an API plugin.

My apologies for the spreadsheet not being clear enough -- Plugins to be part of the initial setup are those with "YES" in the Inclusion column. I stopped around 14k projected installs to not overload the dialog. Any plugins without that "YES" would not appear as entries.

We can always go further down the list if we determine the initial setup could/should have more stuff in it.

Daniel Beck

unread,
Feb 24, 2016, 7:50:55 AM2/24/16
to jenkin...@googlegroups.com

On 24.02.2016, at 13:05, Victor Martinez <victormar...@gmail.com> wrote:

> Mercurial and Perforce are not part of that list, although their usage are not massive compare to Git or SVN, but might be also important to have them as part of the SCM category. That's my point of view and sorry if I said something which it was already said previously.

Good point. As I wrote on the wiki, SCM plugins are special (nothing much going on in Jenkins without them), so I recommend we're more accepting in that category. My current list of SCMs to include are (with approx. install count):

https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin - 76k
https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin - 123k
https://wiki.jenkins-ci.org/display/JENKINS/ClearCase+Plugin - 1500
https://wiki.jenkins-ci.org/display/JENKINS/CVS+Plugin - 120k
https://wiki.jenkins-ci.org/display/JENKINS/GitBucket+Plugin - 1200
https://wiki.jenkins-ci.org/display/JENKINS/Github+Plugin - 20k
https://wiki.jenkins-ci.org/display/JENKINS/Gitlab+Merge+Request+Builder+Plugin - 2000
https://wiki.jenkins-ci.org/display/JENKINS/GitLab+Plugin - 5800
https://wiki.jenkins-ci.org/display/JENKINS/Mercurial+Plugin - 6500
https://wiki.jenkins-ci.org/display/JENKINS/P4+Plugin - 1500
https://wiki.jenkins-ci.org/display/JENKINS/Repo+Plugin - 1300
https://wiki.jenkins-ci.org/display/JENKINS/Team+Concert+Plugin - 1000
https://wiki.jenkins-ci.org/display/JENKINS/Team+Foundation+Server+Plugin - 2900

While Perforce Plugin has more installs than P4, it stagnates, and its wiki page recommends use of P4, which is rapidly growing.

Daniel Beck

unread,
Feb 24, 2016, 8:04:47 AM2/24/16
to jenkin...@googlegroups.com

On 24.02.2016, at 13:05, Victor Martinez <victormar...@gmail.com> wrote:

> What about docker plugin? It might be a good candidate as part of the plugin selection as it's widely used and might alienate the concept of reproducibility and configuration, which are nowadays quite trendy, with Jenkins.

This is an interesting question, and one I wanted to explore once the initial plugins selection is defined:

Could we actually manage to curate a more opinionated list?

Given how the initial discussion last year went, I had my doubts -- hence this reboot that started out with a set of rules/guidelines, rather than a proposed list of plugins. I think the result could be much better, if we were to actually build a list based on our collective experience with Jenkins.

The risk of course is that we're not getting anywhere, as our varying experiences using Jenkins color our opinion what plugins are a "must have". I'm not excluding myself here -- I noticed this with a few plugins I included in the original list, that, when viewed critically, weren't nearly as universally useful as I first considered them to be.

----

That said, I suggest we continue with the current approach of a mostly popularity based list, excluding unmaintained and unsuitable plugins, for now. So please, provide some more feedback on it, and maybe think about ways to make the above work.

Robert Sandell

unread,
Feb 24, 2016, 9:45:35 AM2/24/16
to jenkin...@googlegroups.com
If GitLab and GitHub triggers are on the list because of their SCM affiliation then Gerrit Trigger should be on the list as well.

If the neighbour’s kids gets to go to the Prom then my baby should also go to the Prom! :-p

/B

--
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.

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

Ullrich Hafner

unread,
Feb 24, 2016, 4:14:42 PM2/24/16
to jenkin...@googlegroups.com
How is the initial selection presented to the user? Is there already a mockup or screenshot available? Should the number of plug-ins per category be equal sized? Or are all categories shown in one screen?
E.g., if we have tabs for the categories then choosing e.g. just 3 plug-ins per category makes no sense to me.

Wouldn’t it make more sense to have some kind of profiles like
- Build Java Web Applications
- Deploy to Application Servers
- Analyze Source Code
- Measure Code Coverage
and so on and provide a set of plug-ins per profile? Or is this not feasible due to the enormous number of plug-ins?

While the UI of Eclipse normally is not a good reference for best UI practices I think having something like the different eclipse versions is a good thing (eclipse for java developers, eclipse for testers, etc.)
> --
> 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/044ECC6E-4C39-45B6-90E3-1A0C40BD5E9B%40beckweb.net.
signature.asc

Christopher Orr

unread,
Feb 24, 2016, 4:30:37 PM2/24/16
to jenkin...@googlegroups.com
There's a demo video linked from the "Jenkins 2.0" wiki page:
https://www.youtube.com/watch?v=kzRR8XR8hu4

Though I have a feeling a saw a newer version at FOSDEM; not sure where
the code can be found (not that I've looked).

Regards,
Chris

Manfred Moser

unread,
Feb 24, 2016, 4:47:49 PM2/24/16
to Jenkins Developers
Interesting.. that video reminded me of the email from Olivier about the proxy server config. How will a case be handled were the initial start up in a datacenter requires configuration of a proxy server to be able to get to the internet/update center? 

JVM proxy config or some UI? 

manfred

Luca Milanesio

unread,
Feb 24, 2016, 5:08:18 PM2/24/16
to jenkin...@googlegroups.com
Why BitBucket, GitLab, GitHub and not Gerrit?
Gerrit is 100% OpenSource, whilst the same cannot be said about the others ;-)

Luca.
> --
> 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/D05C72E9-6127-4260-A8FD-0FC3D2E77E3D%40beckweb.net.

Ullrich Hafner

unread,
Feb 24, 2016, 6:09:08 PM2/24/16
to jenkin...@googlegroups.com
Are we talking in this thread about the left or right selection in this demo (or both)? I.e. "Recommended plugins“ or "Customize your Plugins“?
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/56CE20F6.2090904%40orr.me.uk.
signature.asc

Christopher Orr

unread,
Feb 24, 2016, 6:09:30 PM2/24/16
to jenkin...@googlegroups.com
Nice work!

I'm not sure whether `javadoc` (row 17, YES) is a useful suggestion;
it's seemingly only high on the list because it used to be part of core.

Having set up some jobs last week for various types of software
projects, the Javadoc- and Doxygen-specific plugins don't seem to offer
any obvious benefits compared to the generic HTML Publisher plugin (row
49, YES).

I also wonder whether people actually use PAM Authentication (row 15, YES)?

Is it useful to take up a spot in the list for the Translation
Assistance Plugin (row 21, YES) — will anybody really install that?
Do we merge in the unverified user-provided translations more often than
once every two years anyway?
If we want to keep on using this mechanism to get translations, it
should maybe remain bundled with Jenkins, rather than appearing in this
list.

Otherwise, it looks good. Though I'd quite like to see
`throttle-concurrents` on the list, as I feel its usefulness isn't
reflected in its install stats :)

Regards,
Chris

Manfred Moser

unread,
Feb 24, 2016, 6:50:04 PM2/24/16
to Jenkins Developers
I would suggest to add the config file provider plugin in the recommended plugins. It seems to be the best way to provide Maven and other settings file to a cluster without having to provision them on the nodes directly. Unless there is some other preferred method I dont know about. 

Arnaud Héritier

unread,
Feb 24, 2016, 7:04:31 PM2/24/16
to jenkin...@googlegroups.com
The Configuration Slicing plugin is also a must have from my POV


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



--

Daniel Beck

unread,
Feb 25, 2016, 10:57:27 AM2/25/16
to jenkin...@googlegroups.com

On 25.02.2016, at 00:09, Ullrich Hafner <ullrich...@gmail.com> wrote:

> Are we talking in this thread about the left or right selection in this demo (or both)? I.e. "Recommended plugins“ or "Customize your Plugins“?

So far this is about the list of plugins on the right side -- I'd go for the recommended plugins in a second step (as that is a subset).

Daniel Beck

unread,
Feb 25, 2016, 11:01:17 AM2/25/16
to jenkin...@googlegroups.com

On 24.02.2016, at 23:08, Luca Milanesio <luca.mi...@gmail.com> wrote:

> Why BitBucket, GitLab, GitHub and not Gerrit?
> Gerrit is 100% OpenSource, whilst the same cannot be said about the others ;-)

On 24.02.2016, at 15:45, Robert Sandell <rsan...@cloudbees.com> wrote:

> If GitLab and GitHub triggers are on the list because of their SCM affiliation then Gerrit Trigger should be on the list as well.
>
> If the neighbour’s kids gets to go to the Prom then my baby should also go to the Prom! :-p

Uh… because daddy forgot to sign up his baby for the SCM category?

I looked through that category in the wiki and those that looked to be actual SCMs I added to the list…

FWIW the idea was to include actual SCMs, so I may well have been wrong in including these others. WDYT? Should be only apply the more generous rule to actual SCMs, or also "SCM related" plugins?

Daniel Beck

unread,
Feb 25, 2016, 11:03:17 AM2/25/16
to jenkin...@googlegroups.com

On 24.02.2016, at 22:14, Ullrich Hafner <ullrich...@gmail.com> wrote:

> Wouldn’t it make more sense to have some kind of profiles like
> - Build Java Web Applications
> - Deploy to Application Servers
> - Analyze Source Code
> - Measure Code Coverage
> and so on and provide a set of plug-ins per profile? Or is this not feasible due to the enormous number of plug-ins?
>
> While the UI of Eclipse normally is not a good reference for best UI practices I think having something like the different eclipse versions is a good thing (eclipse for java developers, eclipse for testers, etc.)

Most of the UX already exists. We can name the categories freely, and determine which plugins show up (and we may be able to do a bit more than that if we like a different approach better).

The current category proposals are listed on https://wiki.jenkins-ci.org/display/JENKINS/Plugin+Selection+for+the+Setup+Dialog

Daniel Beck

unread,
Feb 25, 2016, 11:04:41 AM2/25/16
to jenkin...@googlegroups.com

On 24.02.2016, at 22:30, Christopher Orr <ch...@orr.me.uk> wrote:

> Though I have a feeling a saw a newer version at FOSDEM; not sure where
> the code can be found (not that I've looked).

It's on the 2.0 branch, and the "2.0-alpha-1" build uploaded by KK earlier this week has the code as well. The plugin selection there is essentially what's currently bundled, but otherwise the UI is there.

Daniel Beck

unread,
Feb 25, 2016, 11:07:28 AM2/25/16
to jenkin...@googlegroups.com

On 25.02.2016, at 00:09, Christopher Orr <ch...@orr.me.uk> wrote:

> If we want to keep on using this mechanism to get translations, it
> should maybe remain bundled with Jenkins, rather than appearing in this
> list.

The existing bundling mechanism has been removed entirely in favor of user controlled selection on first startup.

While we still bundle plugins, those only get installed if backward compatibility requires it (i.e. actual detached plugins when upgrading from a version in which they were part of core).

This also means that all plugins can be uninstalled (rather than just disabled as today), modulo plugin dependencies.

Daniel Beck

unread,
Feb 25, 2016, 11:11:11 AM2/25/16
to jenkin...@googlegroups.com

On 25.02.2016, at 01:04, Arnaud Héritier <aher...@gmail.com> wrote:

> The Configuration Slicing plugin is also a must have from my POV

I've seen too much brokenness from changed data formats (or data it did not support, e.g. email-ext per-trigger emails) etc. to be able to support this. So -1 from me on this suggestion.

Please also remember that this isn't supposed to be the list of everyone's favorite plugins -- it should actually be useful to people _getting started_ with Jenkins. Plugins that allow configuring a hundred projects at once don't seem that relevant to me for that use case.

Robert Sandell

unread,
Feb 26, 2016, 8:24:22 AM2/26/16
to jenkin...@googlegroups.com
On Thu, Feb 25, 2016 at 5:01 PM, Daniel Beck <m...@beckweb.net> wrote:

On 24.02.2016, at 23:08, Luca Milanesio <luca.mi...@gmail.com> wrote:

> Why BitBucket, GitLab, GitHub and not Gerrit?
> Gerrit is 100% OpenSource, whilst the same cannot be said about the others ;-)

On 24.02.2016, at 15:45, Robert Sandell <rsan...@cloudbees.com> wrote:

> If GitLab and GitHub triggers are on the list because of their SCM affiliation then Gerrit Trigger should be on the list as well.
>
> If the neighbour’s kids gets to go to the Prom then my baby should also go to the Prom! :-p

Uh… because daddy forgot to sign up his baby for the SCM category?

I looked through that category in the wiki and those that looked to be actual SCMs I added to the list…

Yes, it only has the trigger category because it doesn't do any scm stuff (except help the git plugin figure out what to checkout). It is however "SCM related" so perhaps it could be argued that it should have the scm label set as well, but I never saw it like that because I've seen the scm categori as "plugins that gets the code from somewhere in some revision to the workspace" And that is not what the trigger does.
But I don't know what is less confusing of the two alternatives :)

FWIW the idea was to include actual SCMs, so I may well have been wrong in including these others. WDYT? Should be only apply the more generous rule to actual SCMs, or also "SCM related" plugins?

Personally, as I wrote above, I've always seen a clear distinction between pure scm plugins and triggers. But when the triggering is based on events in an scm it does get a bit blurry. I have no strong opinion either way, except that if GitLab and GitHub related plugins gets on the list because of their scm relation and not because of install count etc. then Gerrit Trigger should be on the list as well, unless some of the exclusion rules apply of course ;)
The same should probably go for repository browsers for svn et.al.



--
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.

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

Ullrich Hafner

unread,
Feb 26, 2016, 5:35:00 PM2/26/16
to jenkin...@googlegroups.com
I see. Would’t it make sense to have the categories in the spreadsheet? So we can select N plug-ins per category. Otherwise we would choose 3 plug-ins in one tab and 20 plug-ins in another...
> --
> 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/743D290B-8A93-4C64-A668-85EE70DFEABF%40beckweb.net.
signature.asc

Gavin Mogan

unread,
Feb 27, 2016, 2:12:37 AM2/27/16
to Jenkins Developers
I'm incredibly biased since I've spent the last few months improve its stability, but is the sauce labs plugin something that can be added to the list?

Kohsuke Kawaguchi

unread,
Mar 1, 2016, 2:38:10 PM3/1/16
to jenkin...@googlegroups.com

2016-02-25 8:11 GMT-08:00 Daniel Beck <m...@beckweb.net>:
Please also remember that this isn't supposed to be the list of everyone's favorite plugins -- it should actually be useful to people _getting started_ with Jenkins. Plugins that allow configuring a hundred projects at once don't seem that relevant to me for that use case.

What this reminds me is that we need a solution page for people who started feeling the pain of scale.

There are a number of great plugins that the community has developed to help people in this situation, and having a page on jenkins.io that lays them out to people would be awesome.


--
Kohsuke Kawaguchi

Kohsuke Kawaguchi

unread,
Mar 1, 2016, 2:45:21 PM3/1/16
to jenkin...@googlegroups.com
This isn't in the criteria listed in Wiki page, but I always thought we have less incentive to include a plugin that has a clear point of friction (that there is a moment that novice users realize that he needs a plugin) and is easy to discover.

Take CVS plugin for example. When you are configuring a freestyle job, there is the SCM section and you don't see CVS in there, which makes you realize you need a plugin. So it has a clear point of friction.

Then when you go to Plugin Manager, there's one and only "CVS Plugin" and nothing else that shows up in there has a danger of being confusing.

SauceLab, which is actually "Sauce On Demand plugin", fits in this category, I think. It doesn't have a point of friction as clear as CVS plugin, but it's plenty discoverable, and if your team uses Sauce On Demand, you probably think about looking for that in the plugin manager.




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



--
Kohsuke Kawaguchi

Kohsuke Kawaguchi

unread,
Mar 1, 2016, 2:59:53 PM3/1/16
to jenkin...@googlegroups.com
My comments to the current list.

  • PAM auth plugin should be in. It doesn't add any complexity unless used, it should be the default choice for anyone who has a proper Unix setup (like Sun was where there was a corporate wide NIS servers and all desktops & lab machines were pre-configured to use it), and it's hard to discover (PAM is not in a vocabulary of most people)

  • Envinject plugin is marked as "No: unsafe". I'm not up to speed on the details of the actual issue, but it does cover an important functionality that's otherwise hard to discover. Is one of its substitutions in the list? Or could we ask the author of that plugin to look into it? I think we'd like to bundle some plugins that help people deal with environment variables.

  • Ditto for conditional-buildstep. Is it unmaintained, or does it do everything it needs to do?

Also, a part of the value of the recommended plugin set should be that we test that combo for better QA. I think we need to set up acceptance-test runs against this combo. I'm also curious how much of these plugins have any coverage in ATH.

--
Kohsuke Kawaguchi

Slide

unread,
Mar 1, 2016, 3:17:33 PM3/1/16
to jenkin...@googlegroups.com
Comment inline

On Tue, Mar 1, 2016 at 12:45 PM Kohsuke Kawaguchi <k...@kohsuke.org> wrote:
Take CVS plugin for example. When you are configuring a freestyle job, there is the SCM section and you don't see CVS in there, which makes you realize you need a plugin. So it has a clear point of friction.
 
In this case, it would be nice to have some thing in the job configuration that showed you what was available for SCM's. A link to the SCM section of the plugin page would be super useful in cases like this.


Daniel Beck

unread,
Mar 1, 2016, 5:12:03 PM3/1/16
to jenkin...@googlegroups.com

On 26.02.2016, at 23:34, Ullrich Hafner <ullrich...@gmail.com> wrote:

> Would’t it make sense to have the categories in the spreadsheet? So we can select N plug-ins per category. Otherwise we would choose 3 plug-ins in one tab and 20 plug-ins in another

Currently the selection of popular plugins is not imbalanced like this. I suggest we decide on plugins now based on merit, and if we notice in imbalance like you describe, we can always adjust as needed.

Victor Martinez

unread,
Mar 2, 2016, 5:36:45 AM3/2/16
to Jenkins Developers, m...@beckweb.net
Quick question, maybe I'm again repeating the same question over and over, but I've just reviewed the Jenkins2.0 alpha version and for some reason Pipeline plugin is part of the default plugin list, I'm not agains that plugin (just got some concerns about how to run unit/integrations tests without any Jenkins instance, but probably this is another topic to discuss) but IMO, that plugin requires some Jenkins knowledge and might be tough to be used by any newbie Jenkins user, hence it doesn't follow the 4th criteria "Are the features it provides useful to someone fairly new to Jenkins?" 

Cheers

Daniel Mueller

unread,
Mar 2, 2016, 5:43:28 AM3/2/16
to jenkin...@googlegroups.com

I also just tried the alpha release and was a bit buffled why the SCM plugin list would contain SVN and CVS but not Git.  I found out later that the Git plugin seems to be installed by default anyway, maybe you can find a way to make this more clear, I mean I was kinda hoping to find it anyway but you got me confused for a second.

 

PS: Thumbs up for the tabs in job config, a nice addition would be to highlight tabs that require users attention, e.g. config missing. Alltogether I was hoping for a more radical UI change, but that’s just me ;)

 

Mit freundlichen Grüßen / Kind Regards

Daniel Mueller
________________________________________________
OSTHUS GmbH
Eisenbahnweg 9 - 11
Eingang TH 6
52068 Aachen

T    +49 241-94314-
232
F    +49 241-94314-19
daniel....@osthus.com
www.osthus.com

LinkedIn          Twitter            Youtube

 

Handelsniederlassung: 52068 Aachen
Register: Amtsgericht Aachen, HRB 6398
Geschäftsführer: Dr. Torsten Osthus, Wolfgang Colsman, Andreas Mohr
________________________________________________
Der Inhalt dieser E-Mail ist ausschließlich für den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts dieser E-Mail unzulässig ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen.
________________________________________________
The information contained in this email is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any form of disclosure, reproduction, distribution or any action taken or refrained from in reliance on it, is prohibited and may be unlawful. Please notify the sender immediately.

--

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.

Oleg Nenashev

unread,
Mar 2, 2016, 9:36:12 AM3/2/16
to Jenkins Developers, daniel....@osthus.com
Alltogether I was hoping for a more radical UI change, but that’s just me ;)

We've just started.
Jenkins 2.0 is mostly a starting point for real changes in Jenkins.

среда, 2 марта 2016 г., 13:43:28 UTC+3 пользователь Daniel Mueller написал:

Daniel Beck

unread,
Mar 2, 2016, 12:48:27 PM3/2/16
to jenkin...@googlegroups.com

On 02.03.2016, at 11:43, Daniel Mueller <daniel....@osthus.com> wrote:

> I found out later that the Git plugin seems to be installed by default anyway, maybe you can find a way to make this more clear, I mean I was kinda hoping to find it anyway but you got me confused for a second.

The discussion on what to include on the initial setup screen is still ongoing, and Git Plugin is definitely going to be a part of it.

Daniel Beck

unread,
Mar 2, 2016, 12:59:56 PM3/2/16
to jenkin...@googlegroups.com

On 02.03.2016, at 11:36, Victor Martinez <victormar...@gmail.com> wrote:

> that plugin requires some Jenkins knowledge and might be tough to be used by any newbie Jenkins user, hence it doesn't follow the 4th criteria "Are the features it provides useful to someone fairly new to Jenkins?"

Since it's a DSL there is a learning curve you don't have with just clicking around and reading all the options, but you can essentially build a complete Pipeline with just a handful of commands like 'node', 'sh', and 'stash'/'unstash'. OTOH if you want to do anything useful with e.g. the System Groovy build step provided by the Groovy plugin, you already have to know Jenkins internals and have the Jenkins Javadoc open -- it is an entirely different level.

Jesse Glick

unread,
Mar 2, 2016, 2:21:05 PM3/2/16
to Jenkins Dev
On Tue, Mar 1, 2016 at 2:59 PM, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:
> PAM auth plugin should be in. […] it's hard to discover (PAM is
> not in a vocabulary of most people)

Maybe the plugin should just be renamed then. “Unix (PAM) Authentication”?

Ditto `antisamy-markup-formatter` [sic, my fault], which talks about
OWASP that most people are not going to recognize as anything—should
arguably just be “Sanitized HTML Markup Formatter”.

Slide

unread,
Mar 2, 2016, 2:27:09 PM3/2/16
to Jenkins Dev
Maybe this has been answered before, but does a "YES" in the spreadsheet mean it will be installed by default, or be in the recommended wizard?

--
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.

James Nord

unread,
Mar 2, 2016, 3:00:01 PM3/2/16
to Jenkins Developers
So the credentials-binding plugin is something that I feel should be promoted.  It's the recommended (only?) way of securely using credentials within scripts in pipeline - so we should be pointing users towards it - if due to the "good practice" alone.

As for PAM - does anyone use that anymore ;)  (<not_so_serious>in larger installers these days there is windows somewhere - so its LDAP or something else... - and then some orgs won't let Jenkins run on corporate servers but its off in a lab for extra security so no PAM for you</<not_so_serious>) - but it has no wiki documentation so fails on that criteria...

Jesse Glick

unread,
Mar 2, 2016, 3:27:12 PM3/2/16
to Jenkins Dev
On Wed, Mar 2, 2016 at 3:00 PM, James Nord <jn...@cloudbees.com> wrote:
> So the credentials-binding plugin is something that I feel should be
> promoted.

Not sure if my opinion as maintainer of the plugin counts for
anything, but if so, +1. :-)

Ullrich Hafner

unread,
Mar 2, 2016, 5:19:16 PM3/2/16
to jenkin...@googlegroups.com

> Am 25.02.2016 um 00:09 schrieb Christopher Orr <ch...@orr.me.uk>:
>
> Nice work!
>
> I'm not sure whether `javadoc` (row 17, YES) is a useful suggestion;
> it's seemingly only high on the list because it used to be part of core.
>

Yes, I also think that the JavaDoc plug-in is not used very often.

I would also recommend the warnings plug-in (ok, as maintainer I’m biased;-), it shows reports for a lot of different programming languages and compilers (while the selected Checkstyle plug-in shows only reports for Java).

>
> On 23/02/16 23:20, Daniel Beck wrote:
>> Hi everyone,
>>
>> I added two additional criteria to the wiki: The plugin shouldn't require a restart to work (otherwise it's not exactly a great getting started experience), and it shouldn't be just a UI/theming plugins that replaces part of the Jenkins UI (as including them in a list of suggested/recommended plugins would just be weird).
>>
>> Based on these criteria I tried to build a list of plugins to feature in the initial setup wizard.
>>
>> A reminder: All plugins are still available in the plugin manager. But with 1100+ plugins now, it'd be great if we could provide a curated subset to get new users started. This also means that particularly complex plugins, that require knowledge of Jenkins internals, even though they may be useful, are basically excluded by default.
>>
>> To approximate popularity, I used the previous install count multiplied by the growth in the previous year (as neither alone is a sufficient indicator of popularity). Then I sorted by this value, and went through the list, being mildly judgmental. This is the result:
>>
>> https://docs.google.com/spreadsheets/d/1TKziW5oEfX9NYAPrZkz-wXPt5s-zG-znIB5-Jwt3tmw/edit#gid=0
>>
>> This is the list of plugins I came up with for the initial setup dialog. If a plugin wouldn't be used, the reason is stated. Regarding 'Unsafe': Wearing my security officer hat, I consider every plugin with Groovy scripting that is not using the Groovy Sandbox to be unsafe, even if it implements security measures.
>>
>> Please review the list, and let me know what you think.
>>
>>
>> On 21.01.2016, at 19:56, Daniel Beck <m...@beckweb.net> wrote:
>>
>>> Hi everyone,
>>>
>>> For Jenkins 2.0, we're aiming for a much better 'getting started' experience, aimed for users new to Jenkins.
>>>
>>> We already talked about this last year[1], but the discussion didn't really have a great result, so I'd like to start over by defining a list of guidelines on what kind of plugins qualify for inclusion first. My initial proposal is in the wiki[2]. Please take a look and provide feedback in this thread.
>>>
>>> Specific selection of plugins would be the next step.
>>>
>>> Daniel
>>>
>>> 1: https://groups.google.com/forum/#!msg/jenkinsci-dev/w-_18aYn4QQ/t_WT442bBwAJ
>>> 2: https://wiki.jenkins-ci.org/display/JENKINS/Plugin+Selection+for+the+Setup+Dialog
>>>
>>> --
>>> 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/044ECC6E-4C39-45B6-90E3-1A0C40BD5E9B%40beckweb.net.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>
> --
> 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/56CE3824.7010707%40orr.me.uk.
signature.asc

Ullrich Hafner

unread,
Mar 2, 2016, 5:25:59 PM3/2/16
to jenkin...@googlegroups.com
Wouldn’t it be more understandable for beginners if in the installation wizard the abbreviation SCM would be replaced with the full length name as in the other categories?

> Am 24.02.2016 um 13:51 schrieb Daniel Beck <m...@beckweb.net>:
>
>
> On 24.02.2016, at 13:05, Victor Martinez <victormar...@gmail.com> wrote:
>
>> Mercurial and Perforce are not part of that list, although their usage are not massive compare to Git or SVN, but might be also important to have them as part of the SCM category. That's my point of view and sorry if I said something which it was already said previously.
>
> Good point. As I wrote on the wiki, SCM plugins are special (nothing much going on in Jenkins without them), so I recommend we're more accepting in that category. My current list of SCMs to include are (with approx. install count):
>
> https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin - 76k
> https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin - 123k
> https://wiki.jenkins-ci.org/display/JENKINS/ClearCase+Plugin - 1500
> https://wiki.jenkins-ci.org/display/JENKINS/CVS+Plugin - 120k
> https://wiki.jenkins-ci.org/display/JENKINS/GitBucket+Plugin - 1200
> https://wiki.jenkins-ci.org/display/JENKINS/Github+Plugin - 20k
> https://wiki.jenkins-ci.org/display/JENKINS/Gitlab+Merge+Request+Builder+Plugin - 2000
> https://wiki.jenkins-ci.org/display/JENKINS/GitLab+Plugin - 5800
> https://wiki.jenkins-ci.org/display/JENKINS/Mercurial+Plugin - 6500
> https://wiki.jenkins-ci.org/display/JENKINS/P4+Plugin - 1500
> https://wiki.jenkins-ci.org/display/JENKINS/Repo+Plugin - 1300
> https://wiki.jenkins-ci.org/display/JENKINS/Team+Concert+Plugin - 1000
> https://wiki.jenkins-ci.org/display/JENKINS/Team+Foundation+Server+Plugin - 2900
>
> While Perforce Plugin has more installs than P4, it stagnates, and its wiki page recommends use of P4, which is rapidly growing.
>
> --
> 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/D05C72E9-6127-4260-A8FD-0FC3D2E77E3D%40beckweb.net.
signature.asc

Daniel Beck

unread,
Mar 3, 2016, 7:22:30 AM3/3/16
to jenkin...@googlegroups.com

On 02.03.2016, at 20:26, Slide <slide...@gmail.com> wrote:

> does a "YES" in the spreadsheet mean it will be installed by default, or be in the recommended wizard?

So far, this is the selection of available plugins only.

Daniel Beck

unread,
Mar 3, 2016, 7:28:40 AM3/3/16
to jenkin...@googlegroups.com

On 02.03.2016, at 23:25, Ullrich Hafner <ullrich...@gmail.com> wrote:

> abbreviation SCM would be replaced with the full length name as in the other categories?

Great minds think alike:
https://github.com/jenkinsci/jenkins/pull/2061/files#diff-b344e42853e15cd019f7758ab9783ad0R67

:-)

Samuel Van Oort

unread,
Mar 3, 2016, 2:07:18 PM3/3/16
to Jenkins Developers, m...@beckweb.net
Would it make sense to add pipeline-stage-view plugin as a candidate for inclusion alongside the pipeline DSL?  
It provides greatly improved out-of-box experience for new users of pipeline. 


As far as the wiki criteria go:

* While it was recently released to the full public, it had 60+ watchers just on the release issue (JENKINS-31154) and social media activity around it, plus people watching the source repo even before content landed, so we can safely say it is of general interest
* It integrates well with Jenkins, of course, since it was part of a tested codebase
* Not just discoverable, features are fairly understandable out-of-box and ease the path for a new user to pipeline (as well as helping people scaling up in jenkins and moving into full CD use)
* Hosted on JenkinsCI, yes
* Maintained: yes, quite.  *coughs.*

On Thursday, January 21, 2016 at 1:56:15 PM UTC-5, Daniel Beck wrote:
Hi everyone,

Robert Sandell

unread,
Mar 4, 2016, 6:39:28 AM3/4/16
to jenkin...@googlegroups.com
The stage View is presented front and center on the Jenkins 2.0 preview page, so it would be weird if that plugin wasn't in the initial plugin selection.

https://jenkins-ci.org/2.0/

/B

--
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.

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

Daniel Beck

unread,
Mar 9, 2016, 7:01:05 PM3/9/16
to jenkin...@googlegroups.com

On 23.02.2016, at 23:20, Daniel Beck <m...@beckweb.net> wrote:

> Hi everyone,
>
> I added two additional criteria to the wiki: The plugin shouldn't require a restart to work (otherwise it's not exactly a great getting started experience), and it shouldn't be just a UI/theming plugins that replaces part of the Jenkins UI (as including them in a list of suggested/recommended plugins would just be weird).
>
> Based on these criteria I tried to build a list of plugins to feature in the initial setup wizard.
>
> A reminder: All plugins are still available in the plugin manager. But with 1100+ plugins now, it'd be great if we could provide a curated subset to get new users started. This also means that particularly complex plugins, that require knowledge of Jenkins internals, even though they may be useful, are basically excluded by default.
>
> To approximate popularity, I used the previous install count multiplied by the growth in the previous year (as neither alone is a sufficient indicator of popularity). Then I sorted by this value, and went through the list, being mildly judgmental. This is the result:
>
> https://docs.google.com/spreadsheets/d/1TKziW5oEfX9NYAPrZkz-wXPt5s-zG-znIB5-Jwt3tmw/edit#gid=0
>
> This is the list of plugins I came up with for the initial setup dialog. If a plugin wouldn't be used, the reason is stated. Regarding 'Unsafe': Wearing my security officer hat, I consider every plugin with Groovy scripting that is not using the Groovy Sandbox to be unsafe, even if it implements security measures.
>
> Please review the list, and let me know what you think.

Hi everyone,

based on all the feedback in this thread, I updated the spreadsheet linked above, and opened a PR based on that:

https://github.com/jenkinsci/jenkins/pull/2111

The PR description explains in detail what I did, and why. I plan to include this selection in the next 2.0 preview.

I'd be happy to incorporate further feedback. Please provide it in this thread, and not the PR, to not fragment this conversation.

Samuel Van Oort

unread,
Mar 10, 2016, 10:17:05 AM3/10/16
to Jenkins Developers, m...@beckweb.net
The list looks generally really solid (as do the recommendations). 

Looking at it, a couple comments:

- Would it make sense to put parameterized trigger in the initial recommended plugins?
- Is gradle plugin use strong enough to make it part of the core recommended plugins?
- Junit & checkstyle would probably make sense in the top recommended plugins list

Embeddable build status plugin would be a strong candidate for inclusion.  I'm not sure what category would be best, but "Organization and Administration" and "Build Features" both make some sense. 

Distributed builds is feeling very thin so far (as you've mentioned), perhaps some of the docker stuff:

- docker-plugin (fills the distributed *and* docker categories, woo)
- docker-workflow plugin?  (the docker pipeline).  Or possibly under pipelines?

Robert Sandell

unread,
Mar 10, 2016, 10:39:13 AM3/10/16
to jenkin...@googlegroups.com
What makes antisamy-markup-formatter an Organization type plugin? I would have thought it to be Security related?

/B

--
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.

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

Daniel Beck

unread,
Mar 10, 2016, 10:46:58 AM3/10/16
to jenkin...@googlegroups.com

On 10.03.2016, at 16:39, Robert Sandell <rsan...@cloudbees.com> wrote:

> What makes antisamy-markup-formatter an Organization type plugin? I would have thought it to be Security related?

The default is no formatting at all (escaping all the things). This allows you to use a 'safe' subset of HTML. It's also relevant if you have allow-everyone-to-do-anything security, and don't care about rela