Jenkins 2.0 initial setup plugin selection

[Daniel Beck]

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]

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]

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]

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]

#19 

maven-plugin

100810

126144

157844

No: We don’t really want people to use this

LOL, even if I agree, all Maven users will install it ....

Evil but highly used :(

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/73110AB5-7D59-4858-8A12-F20F64180CA9%40beckweb.net.

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

--

-----

Arnaud Héritier

http://aheritier.net

Mail/GTalk: aheritier AT gmail DOT com

Twitter/Skype : aheritier

[Daniel Beck]

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]

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 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFNCU-8pFthuD3%2BNjMTfVca0sJph6-5uZtYNqjJ%2Bs056xtGwgA%40mail.gmail.com.

[Oliver Gondža]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/56CD56F7.7020200%40gmail.com.

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

--

Robert Sandell

Software Engineer

CloudBees Inc.

[Robert Sandell]

... and gravatar.

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

/B

[Victor Martinez]

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]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/1C2691DD-F00D-43B7-867C-FC8E230985E9%40beckweb.net.

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

[Ullrich Hafner]

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.

[Christopher Orr]

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]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/56CE20F6.2090904%40orr.me.uk.

[Luca Milanesio]

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]

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.

[Christopher Orr]

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]

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. 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/56CE3824.7010707%40orr.me.uk.

[Arnaud Héritier]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CABffhO4x8dsB2KerWjWbijFtcubLPxjWSEQ6R5MFhpx6gUbcoA%40mail.gmail.com.

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

--

[Daniel Beck]

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]

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]

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]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/F0DAE31A-7259-4984-881A-3A1ADEF6EBF9%40beckweb.net.

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

[Ullrich Hafner]

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.

[Gavin Mogan]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/5753edbe-7323-48c6-a95c-3887212cf103%40googlegroups.com.

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

--

Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4wDTDjrQ273gTM%2BUsZDhxzruZ_WYEY13DfTiz0M90hCaQ%40mail.gmail.com.

[Daniel Beck]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/b45c67c9-4a17-4ebd-9d8a-a768189c317b%40googlegroups.com.

[Oleg Nenashev]

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]

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]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0rZQXF9Acmq8aZ5x0qhzD2jfOty9N9LJkVuQtqhftp2A%40mail.gmail.com.

[James Nord]

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]

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]

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

[Ullrich Hafner]

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.

[Daniel Beck]

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]

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]

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. 

https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Stage+View+Plugin

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/f5777d5a-cf6e-42af-971b-651883391c0c%40googlegroups.com.

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

[Daniel Beck]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/4fe3a3db-b44e-45ae-aad0-3df96677463e%40googlegroups.com.

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

[Daniel Beck]

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 related plugins. FWIW I mentioned that one a while back on the wiki page as example where these categories have overlap.

[Daniel Beck]

On 10.03.2016, at 16:17, Samuel Van Oort <svan...@cloudbees.com> wrote:
>
> 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.

Noted. FWIW I see this more in the former category. 'Build Features' is a hack anyway and I would love to see some other suggestions…

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

Are both of them strong enough if we don't consider the category issue? Worst case we'll need to rethink those so it makes sense for the plugins we suggest to new users.

-----

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

I guess we're starting the conversation on the initial plugin selection now? :-)

A reminder:

> For the recommended plugins, I had to improvise, as these have not been discussed yet. Despite this I decided to provide a "real" selection as we've received quite confused/negative feedback on the previous list contents, and didn't want that repeated with the recommended plugins list.

Your suggestions look sensible. FWIW I mainly added Gradle (and Ant) to not have that category empty (and failed to do the same for build analysis…). Maven plugin is out of the list, and Maven build step is a core feature, so the list lacks wrt those.

[Samuel Van Oort]

On Thursday, March 10, 2016 at 10:58:38 AM UTC-5, Daniel Beck wrote:

On 10.03.2016, at 16:17, Samuel Van Oort <svan...@cloudbees.com> wrote:
>
> 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.

Noted. FWIW I see this more in the former category. 'Build Features' is a hack anyway and I would love to see some other suggestions…  

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

Are both of them strong enough if we don't consider the category issue? Worst case we'll need to rethink those so it makes sense for the plugins we suggest to new users.

Having worked with it extensively at this point, the docker pipeline is *definitely* strong enough; the warts are mostly around the initial docker configuration.

I mention the docker-plugin because it is quite popular (doubled installation in the last year), and has guides for using it out: 

https://developer.jboss.org/people/pgier/blog/2014/06/30/on-demand-jenkins-slaves-using-docker?_sscc=t

https://wiki.bitnami.com/Applications/BitNami_Jenkins/Configure_Jenkins_container_slaves

Presently I'm using the docker pipeline for similar use cases (and then some), but it seems like a logical choice for many users.  

Or at least there should be another option out of the docker options to suggest for distributed builds in docker containers (whether it's this, docker-slaves, or docker custom build environment, etc etc).  Since this is a common use cast, it would be quite helpful to have a specific option for users.

 

-----

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

I guess we're starting the conversation on the initial plugin selection now? :-)

Did I stick a foot in it? :-)  The general recommendations there seem overall quite sensible though, but perhaps I'll un-stick my foot since this may be a tad contentious.

[James Nord]

Why include CVS when Perforce is not included?  do we expect people who are still using CVS to suddenly think they need a CI system rather than a change of SCM :-)

I would think that both are equally niche markets these days (for very different reasons)  - so include both or neither.

[Daniel Beck]

On 10.03.2016, at 20:43, James Nord <jn...@cloudbees.com> wrote:

> Why include CVS when Perforce is not included?

I included P4 Plugin, rather than Perforce Plugin, based on a recommendation by Oleg.

[Daniel Beck]

On 10.03.2016, at 01:00, Daniel Beck <m...@beckweb.net> wrote:

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

Hi everyone,

KK released 2.0 alpha 3 earlier today. It contains a list of plugins based on the recommendations in this thread (up until ~2 days ago), but due to a bug I had to temporarily remove several to not make the first run experience terrible. See the PR linked above for more details. Once the bug is fixed, the full plugin list will be restored.

Just in case you're checking out this new build and are wondering why several popular plugins are missing.

Daniel

[Daniel Beck]

On 12.03.2016, at 00:33, Daniel Beck <m...@beckweb.net> wrote:

> KK released 2.0 alpha 3 earlier today. It contains a list of plugins based on the recommendations in this thread (up until ~2 days ago), but due to a bug I had to temporarily remove several to not make the first run experience terrible. See the PR linked above for more details. Once the bug is fixed, the full plugin list will be restored.
>
> Just in case you're checking out this new build and are wondering why several popular plugins are missing.

An update to this thread:

In the alpha 4 release which happened last week, we fixed the bug and included all the commented-out plugins again. So that's the list as suggested in this thread.

Since then I've filed PRs 2151 and 2152 to address the following issues:

* Slack plugin got a 2.0.1 release with fix for the instance-breaking bug
* embeddable-build-status, recommended by Sam, was added
* build-monitor-plugin and sonar removed as they are ineligible (not hosted in jenkinsci)

Regards
Daniel

[Daniel Beck]

Hi everyone,

I hope by now most of you had the opportunity to check out alpha 3 or alpha 4. I'd like to know what you think of the default plugins selection. What do you think should be included?

As I've written before I tried to build a useful list for alpha 3 as a starting point, but didn't have the time to discuss it without delaying the alphas. But we have still the time to change things towards 2.0. And with a change I hope to get in shortly after 2.0, Jenkins will retrieve the list from the update site, so we can always tweak it, even for past releases[1].

If you're not able to try the setup wizard right now, you'll also find the lists of both the available and the recommended plugins in [2]. "Available" means users are able to select them during installation (which has been discussed here so far), and "recommended" is the set of plugins that are 'checked by default' if the user wants to customize, and will be installed if the user chooses to accept the defaults.

1: https://issues.jenkins-ci.org/browse/JENKINS-33299
2: https://github.com/jenkinsci/jenkins/blob/2.0/war/src/main/js/api/plugins.js

[Baptiste Mathus]

Wondering if BuildTriggerBadge could/should make it in the "build features" part (disclaimer: my first plugin).

It lets you quickly know what triggered a build. Without the recent glitch in stats, it would have gone above 3k installs in the last month I think. 

It was judged useful by Praqma too apparently :).

I admit I'm certainly not the best person to judge it :), but really I know find it really hard to look at a builds list in the job page when it's not installed.

IIRC it's a bit below the threshold Daniel set, but I think it's quite general purposed, and somehow improves the UX w/o normally being a "risky" thing from any PoV I guess.

Live example on https://ci.jenkins-ci.org/job/jenkins_2.0/ for example.

WDYT?

--
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/7CEC8F5E-D0CC-453A-B411-CC4ABE9721F4%40beckweb.net.