[RFC] publishers as a drop-down menu

[Kohsuke Kawaguchi]

Following up the conversation from JUC Paris, I pushed the "publisher"
branch to the repository that changes the publisher configuration UI.
I'd like to get feedback on whether people think this is a good idea
or a bad idea.

Currently, the "post-build action" of the project configuration page
lists one checkbox per one publisher. This has a couple of problems:

- when you have a large number of plugins, as many large instances
inevitably do, they occupy a large real estate in the configuration
screen.

- you cannot reorder them

In the branch, instead of a big list of checkboxes, you get a
drop-down menu button just like the main "build' section. And then
you'll be adding publishers by clicking them.

- once you add a publisher of a certain kind, it gets grayed out and
prevents you from adding 2nd (and if you actually click the grayed out
item, you jump to the corresponding part of the page.) (this
restriction of one instance per one publisher might be something worth
removing in the future?)

- new items are inserted into their preferred position, instead of
getting added to the bottom, so that users normally wouldn't have to
think about the proper ordering among them (you generally want the
data collection tasks to come before the notification tasks.)

- a few animations to go with it.

Looking forward to hearing back.

--
Kohsuke Kawaguchi

[Bruno P. Kinoshita]

+1

Didn't have time to try it yet, but the idea seems good, and this way I believe I wouldn't have to use ordinals in extension annotations anymore to change the execution order :-)

Will give it a try during the weekend. 

Thanks!

Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com

>________________________________
> From: Kohsuke Kawaguchi <k...@kohsuke.org>
>To: jenkin...@googlegroups.com
>Sent: Thursday, 19 April 2012 1:01 PM
>Subject: [RFC] publishers as a drop-down menu

[Emanuele Zattin]

It looks great Kohsuke! 

I'm about to leave for some holidays so I won't be able to to it out anytime soon, but my +1 is all yours :)

Thanks!

Emanuele Zattin
---------------------------------------------------
-I don't have to know an answer. I don't feel frightened by not knowing things; by being lost in a mysterious universe without any purpose — which is the way it really is, as far as I can tell, possibly. It doesn't frighten me.- Richard Feynman

[cjo]

Looks good, 

Will this get a new jelly tag so that plugins can use the same type of effect as many want this type of behaviour. Only allowing one instance of an element from a large list of many.

The one I can think of is the parametrized-trigger plugin and https://issues.jenkins-ci.org/browse/JENKINS-8916.

Chris 

[Stephen Connolly]

+1 and add same for triggers

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen

[Bap]

Quoting Kohsuke Kawaguchi <k...@kohsuke.org>:

+1
As creator of the [Flexible Publish Plugin][1], I think this is an
excellent idea.

The two main drivers for Flexible Publish were:
1. Set the order of execution
2. Allow a publisher to be used more than once

I'm all for removing the single instance of a type restriction - some
publishers do not work when run more than once, but many are more than
happy. We could create a marker interface to enable post-build tasks
to either opt in or opt out of multiple use.

Many of the issues of using a publisher more than once are due to the
fact that the data binding does not expect there to be more than one
instance in a page, and form submission results in unexpected (mixed
up) configurations. Those plugins just need some view TLC to enable
them to be used sucessfully more than once (ie. in [Promoted
Builds][2] and Flexible Publish)
Of course there are also many post build tasks that cannot (should
not) run multiple times for very good reasons.

Looking forward to trying out the change at the weekend,
Bap.

[1]: https://wiki.jenkins-ci.org/display/JENKINS/Flexible+Publish+Plugin
[2]: https://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin

>
> --
> Kohsuke Kawaguchi

[Jørgen Tjernø]

I like this, definitely would be good.

At this point they're getting very similar to build steps (not a bad
thing, per se), and that train of thought lead me to consider one
thing:
Could we not simplify the whole set of job configuration by making
build tasks & publishers the same thing? Does the separation of
publishers & build steps gain us anything? They're all "actions" that
are taken (in a sequence) for each build performed.
With a few changes to make it so that build tasks could behave like
post-build tasks ("always run" as opposed to "don't run if build
failed", etc), it seems feasible to me. The benefit would be a simpler
UI, simpler codebase and the opportunity for more re-use. The
complexity of the Jenkins codebase is definitely significant for new
people to start developing - both plugins & core changes.

Does anyone else have any thoughts on this?

- Jørgen.

[Vojtech Juranek]

+1

especially ordering of post-build actions is IMHO great idea
* from user perspective - it's clear in which order plugins run and it can be
changes by user
* from developer perspective - no need to worry what other plugins do and
avoid problems like JENKINS-12962

[domi]

+1
Absolutely positive on this one and I would like to see the same for triggers too…
Domi

> <publisher.png>

[Mirko Friedenhagen]

+1 makes things more transparent.

Regards Mirko
--
Sent from my phone
http://illegalstateexception.blogspot.com
http://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/

[Kohsuke Kawaguchi]

All right, thanks for the feedback. Merged toward 1.463.

Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Nectar, our professional version of Jenkins

[Kohsuke Kawaguchi]

On 04/19/2012 02:50 PM, Jørgen Tjernø wrote:
> I like this, definitely would be good.
>
> At this point they're getting very similar to build steps (not a bad
> thing, per se), and that train of thought lead me to consider one
> thing:
> Could we not simplify the whole set of job configuration by making

> build tasks& publishers the same thing? Does the separation of
> publishers& build steps gain us anything? They're all "actions" that

> are taken (in a sequence) for each build performed.

Yes, the distinction is starting to blur indeed.

One difference that I'm aware of is that if the builder fails, later
builders won't execute, but publishers still get to run.

> With a few changes to make it so that build tasks could behave like
> post-build tasks ("always run" as opposed to "don't run if build
> failed", etc), it seems feasible to me. The benefit would be a simpler
> UI, simpler codebase and the opportunity for more re-use. The
> complexity of the Jenkins codebase is definitely significant for new
> people to start developing - both plugins& core changes.

Because of the backward compatibility requirements, I suspect this
change is likely add to more complexity, at least for a short term. That
is not to say we shouldn't do it. but it'd have the opposite effect for
100 or 200 releases to come until we retire the old abstractions.


On the broader issue of the complexity, maybe we can actually start
deleting some code that's marked deprecated long enough.

For example, Mailer.DESCRIPTOR field is deprecated since 1.286 and
anyone building against >=1.355 is prevented by compiler to link to this
field. That's almost 200 releases of deprecation.

Or BuildStepCompatibilityLayer is there to keep Builder/Publisher from
pre 1.150 working. That's more than 300 releases ago.

Do you think those would help? Or do you see the complexity in places
other than compatibility related things?

[Kohsuke Kawaguchi]

On 04/19/2012 11:51 AM, Bap wrote:
> As creator of the [Flexible Publish Plugin][1], I think this is an
> excellent idea.
>
> The two main drivers for Flexible Publish were:
> 1. Set the order of execution
> 2. Allow a publisher to be used more than once
>
> I'm all for removing the single instance of a type restriction - some
> publishers do not work when run more than once, but many are more than
> happy. We could create a marker interface to enable post-build tasks
> to either opt in or opt out of multiple use.

I think we'll let publishers tell core if they want to allow multiple
instances, and we can treat them accordingly.

>
> Many of the issues of using a publisher more than once are due to the
> fact that the data binding does not expect there to be more than one
> instance in a page, and form submission results in unexpected (mixed
> up) configurations. Those plugins just need some view TLC to enable
> them to be used sucessfully more than once (ie. in [Promoted
> Builds][2] and Flexible Publish)
> Of course there are also many post build tasks that cannot (should
> not) run multiple times for very good reasons.
>
> Looking forward to trying out the change at the weekend,
> Bap.
>
> [1]: https://wiki.jenkins-ci.org/display/JENKINS/Flexible+Publish+Plugin
> [2]: https://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin
>
>>
>> --
>> Kohsuke Kawaguchi
>
>
>

[domi]

Kohsuke,
I think thats a good idea, we should think about code we could remove - 300 Releases after deprecation should be long enough
Domi

[Jørgen Tjernø]

On Wed, Apr 25, 2012 at 11:06 PM, Kohsuke Kawaguchi
<kkawa...@cloudbees.com> wrote:
> On 04/19/2012 02:50 PM, Jørgen Tjernø wrote:
>> With a few changes to make it so that build tasks could behave like
>> post-build tasks ("always run" as opposed to "don't run if build
>> failed", etc), it seems feasible to me. The benefit would be a simpler
>> UI, simpler codebase and the opportunity for more re-use. The
>> complexity of the Jenkins codebase is definitely significant for new
>> people to start developing - both plugins&  core changes.
>
>
> Because of the backward compatibility requirements, I suspect this change is
> likely add to more complexity, at least for a short term. That is not to say
> we shouldn't do it. but it'd have the opposite effect for 100 or 200
> releases to come until we retire the old abstractions.

That makes sense - another possibility would be to rearchitect this
completely, then write a "compatibility layer" that goes between old
plugins and the core (or have a special case for old plugins in the
core). That way the code path for "new plugins" would be clean, and we
could eventually deprecate the compat layer.

> On the broader issue of the complexity, maybe we can actually start deleting
> some code that's marked deprecated long enough.
>

> Do you think those would help? Or do you see the complexity in places other
> than compatibility related things?

I agree that we should remove deprecated code, but I think the
complexity I am the most bothered by is in the code paths that are
still encouraged. There are just a *lot* of different abstractions and
concepts in core.


--
Jørgen.

[Rob Petti]

Love it!

[Mike Rooney]

On Thursday, April 26, 2012 2:07:43 AM UTC-4, Kohsuke Kawaguchi wrote:

On 04/19/2012 11:51 AM, Bap wrote:

> I'm all for removing the single instance of a type restriction - some
> publishers do not work when run more than once, but many are more than
> happy. We could create a marker interface to enable post-build tasks
> to either opt in or opt out of multiple use.

I think we'll let publishers tell core if they want to allow multiple
instances, and we can treat them accordingly.

 

FWIW, I'm for just removing the restriction as Bap is, but instead allowing an annotation that says they /can't/ be run multiple times. The reasoning is that as Bap said, many publishers work fine when run multiple times, and why force users without coding experience to file a bug, hope the maintainer finds it, figures out how to enable this, get a release out, et cetera, just to get a behavior that might already work if they just tried it? If the publisher doesn't work out of the box, that will be immediately discovered, and /that/ to me seems like the case when a bug should be filed, and the plugin can either be blacklisted or adjusted if it makes sense.

Anyway, just a thought, but I think by forcing plugins to be whitelisted it will cut out a lot of interesting emergent uses of publishers by uses without the ability or understanding to enable this functionality themselves.

- Mike

[Peter Franzén]

Hi,

A great improvement, but some Plugins are not added when I select them.
I tried some and works perfectly, but I can not add:
Coverity
Editable Email Notification

Just nothing happens when I select them

/Peter

[Ulli Hafner]

While I think that reordering and showing only active plug-ins is a great improvement I think the selection of the action still is not optimal. Using a List Box Button to select publishers is not very user friendly (at least if you have more than 10 available). Especially when you need to scroll to the bottom of the list it needs quite a lot of time until you reach the last element of the list (maybe the scrolling can be improved anyway). The same pattern is currently used for the portlets selection in the dashboard view and I think it could be also improved by using a more intuitive selection "view". E.g., something in the style of the Jira dashboard selection. In Jira when you press the add button on the dashboard then a selection dialog is opened where you see small previews of the available portlets. This would also make sense for the publishers: here we can show a small icon, a description, etc. Maybe we can also groupd by category...

Ulli


On 05/11/2012 12:40 PM, Peter Franzén wrote

[domi]

Ulli, thats a really good idea!!!!

I think the sam would actually be helpful for triggers, these are getting more and more too…

Domi

[Paul Eipper]

Very good feature. I also vote to remove the multiple plugins restriction, at least Publish Over SSH even lists that as a way to perform multiple commands on its help:
"If you want to Exec before the files are transferred, use 2 Transfer Sets and move the Exec command before the Transfer set that includes a Source files pattern."

--
Paul Eipper

[Slide]

This feature seems to have broken some custom JS that is in the
email-ext plugin. In the config.jelly it has a couple script blocks.

One near the top looks like this:

<script...>var extEmailInit = new Array();</script>

Then later this variable is used

<script...>if(extEmailInit['...'] != null) { }</script>

In the second code block, extEmailInit is not defined and so throws an
error in the JS console of the browser. How do I update the plugin to
still support this custom JS block and have it work correctly?

Thanks,

slide

--
Website: http://earl-of-code.com

[Harry G.]

+1 for this, the ability to add a post-build step multiple times really should be default
This opens up a lot of new possibilities!