pilabs.com
>
> From: Kohsuke Kawaguchi
>To: jenkinsci-dev@googlegroups.com
>Sent: Thursday, 19 April 2012 1:01 PM
>Subject: [RFC] publishers as a drop-down menu
>
>Following up the conversation from JUC Paris, I pushed the "publisher&quo
t;
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
>
> >
> > From: Kohsuke Kawaguchi
> >To: jenkinsci-dev@googlegroups.com
> >Sent: Thursday, 19 April 2012 1:01 PM
> >Subject: [RFC] publishers as a drop-down menu
> >
> &
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
+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
On Apr 19, 2012 5:01 p.m., "Kohsuke Kawaguchi" wrote:
> Following up the conversation from JUC Pa
Quoting 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
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
+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
On Thursday 19 April 2012 1
+1
Absolutely positive on this one and I would like to see the same for triggers
too…
Domi
On 19.04.2012, at 18:01, Kohsuke Kawaguchi wrote:
> Following up the conversation from JUC Paris, I pushed the "publisher"
> branch to the repository that changes the publisher configuration UI.
> I'd li
+1 makes things more transparent.
Regards Mirko
--
Sent from my phone
http://illegalstateexception.blogspot.com
http://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/
On Apr 19, 2012 6:01 PM, "Kohsuke Kawaguchi" wrote:
> Following up the conversation from JUC Paris, I pushed the
All right, thanks for the feedback. Merged toward 1.463.
On 04/19/2012 09:01 AM, Kohsuke Kawaguchi wrote:
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
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
bui
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 r
Kohsuke,
I think thats a good idea, we should think about code we could remove - 300
Releases after deprecation should be long enough
Domi
On 26.04.2012, at 08:06, Kohsuke Kawaguchi wrote:
> On 04/19/2012 02:50 PM, Jørgen Tjernø wrote:
>> I like this, definitely would be good.
>>
>> At this po
On Wed, Apr 25, 2012 at 11:06 PM, Kohsuke Kawaguchi
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 benefi
Love it!
On Thursday, 19 April 2012 10:01:26 UTC-6, Kohsuke Kawaguchi wrote:
>
> 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
> o
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
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
Den torsdagen den 19:e april 2012 kl. 18:01:26 UTC+2 skrev Kohsuke
Kawaguchi:
>
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 scrol
Ulli, thats a really good idea
I think the sam would actually be helpful for triggers, these are getting more
and more too…
Domi
On 13.05.2012, at 19:18, Ulli Hafner wrote:
> While I think that reordering and showing only active plug-ins is a great
> improvement I think the selection of the
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 tha
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:
var extEmailInit = new Array();
Then later this variable is used
if(extEmailInit['...'] != null) { }
In the second code block,
+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!
Am Donnerstag, 10. Mai 2012 20:28:53 UTC+2 schrieb Mike Rooney:
>
> FWIW, I'm for just removing the restriction as Bap is, but instead
> allowing an annotation that
22 matches
Mail list logo
