Quoting domi <[email protected]>:
don't get me wrong, I see your point but whats the difference in
frequently updating plugin B instead of plugin A?
This is my point - there should not be a single 2nd plugin called
"Extra" which is a dump of all run conditions.
There should be a plugin for the run condition - or a few closely
related conditions - named appropriately.
If I have not installed B because I don't use any conditions from B,
then I wont need to update anything.
Your first argument for the second plugin was to reduce the number
of options in the plugin, now
if the admin wants a single condition of the second plugin, he has
exactly the dame issue again?
The point I was making there, is that if everything is in one or 2
plugins, then you will have an all or nothing situation. If the
conditions are in plugins named for what they do, then installing a
plugin to achieve your goal is probably going to add 1, 2, maybe 3
conditions to your list - thus keeping the list in the GUI manageable.
The third point is that there are some conditions that I definitely
will not want on my instance (and I'm sure there will be more in the
future).
Again, If there are separate plugins, I can choose what to install on
my instance.
Regards,
Bap
regards Domi
On 29.06.2012, at 09:35, Bap wrote:
Quoting domi <[email protected]>:
would't it not make more sense to add a configuration option for
the admin to enable/disable specific conditions?
by just adding a new plugin with another X-Conditions, the admin
still only has the option for all or nothing?
?just my 5 cents?
/Domi
Jenkins has an elegant extension system which means that if you
want something on your Jenkins instance, you install it. No
configuration is necessary, the additional functionality just works.
I don't understand why you'd remove the ability of the admin to
choose what goes on their instance by bundling every possible
extension that anyone may want into one package - and then write
additional code that will require the admin to configure what they
do not want to be available.
Using a single plugin would also create an unnecessarily frequent
update cycle - as you'd get an upgrade notification when a new
condition gets added to the "bucket of stuff", or if *any* of the
conditions had an update or bug fix - conditions that you may not
even use.
Regards,
Bap.
On 27.06.2012, at 17:03, Bap wrote:
Sorry, this was supposed to have gone to the list ...
----- Forwarded message from Bap <[email protected]> -----
Date: Wed, 27 Jun 2012 14:33:46 +0100
From: Bap <[email protected]>
Subject: Re: New extra run conditions plugin to fork to jenkinsci
To: cjo <[email protected]>
Quoting cjo <[email protected]>:
Hi,
Can someone with permission please fork
https://github.com/cjo9900/extra-run-conditions-plugin
Please also create Jira component for this.
My github and jenkins-ci username is cjo9900
This plugin will contain extra conditions for the run-condition plugin,
these are separate than the main plugin as suggested by Bap in
https://github.com/jenkinsci/run-condition-plugin/pull/6
Can this plugin be named for what it provides eg
Build+Cause+Run+Condition ?
The reason is that if we just have one big bucket, then you can
only add all or none of the conditions.
This means that:
1. the list of conditions in the drop down will continue to grow
into an ever longer list containing everything that anyone might
want to switch on - which will become very painful if you only
use a couple of conditions
2. an admin cannot make a decision as to what is available on the
instance (eg. I do not want any generic scripting within a job
configuration ...)
The extension mechanism gives the admin the ability to choose
what is available in a jenkins instance, I'd rather not have to
write code and a configuration interface to disable extensions
that I don't want
Cheers,
Bap.
Wiki page has been created for this at
https://wiki.jenkins-ci.org/display/JENKINS/Extra+Run+Conditions+Plugin
Thanks
Chris
----- End forwarded message -----
