Re: How to enable a publisher by default?

I think what I want is a Publisher because I actually want to generate reports and put them in the UI. Although maybe a build listener could do that too.

I can explain my use case a little more,

The scenario I have that might make my use case different is that I have a Hudson installation that I want shared by a team. Sometimes a policy is made that all artifacts should have certain reports generated. If the maintainer of the Hudson instance could configure this once, through a global setting, then all the N projects different users add to Hudson would automatically get these reports with little effort. They wouldn't have to do extra clicking to enable this sort of thing. My current thinking is that for any archived artifacts, I'd automatically generate code coverage and findbugs reports. Publishing javadocs automatically by running javadoc over any jar/class artifa
 cts could be another I'd explore shortly after that.

Users can configure this each time for each project, but people might select different settings - and probably more importantly, the user just perceives extra work.  Introducing new tools can be  challenging, so whenever I can look for ways to make it as simple as possible.  This seemed like a good place to do something like because the alternative is to write a wiki note somewhere that explains what to check and what to put in different text fields. (Its not hard, I agree - but for me its all about making things simple)

--

The approach of letting Publishers fill in their own fields is interesting. I think this might be a good approach. Would it be possible to somehow to auto-check that check box as well?

On 1/29/07, Kohsuke Kawaguchi <Kohsuke.Kawaguchi@xxxxxxx> wrote:

One approach that I can think of is not to implement it as a Publisher
but rather use a listener (we don't have BuildListener right now, but we
can add one.) You won't get any per-job configuration, nor jobs don't
get opportunity to disable something, but depending on what you are
trying to do, this might be a good trade-off (like, say, producing a log.)

The other approach I can think of is to allow Publishers to nominate
themselves as "enabled by default", presumably because they are
important enough. The part that's not clear to me is how Publishers know
that they should be enabled by default. We already have perhaps 10 or so
publishers, yet I've never encountered a case where I thought it should
be enabled by default. So I'm wondering what is so different with your
publisher that makes it special.

Perhaps another approach could be to let publishers fill in form fields
even if it's disabled --- in this way, the only thing the user needs to
do is to click the checkbox, and he gets everything else pre-configured.
   This might be less intrusive, as the user still retains the
perception of the control.

Finally, your hack of calling addPublisher should also work. You just
need to call save() after that to persist that setting.


Eric Crahen wrote:
> For some of the plugins I'm writing, I'm creating a global config. I'd like
> to actually apply this global configuration by default to new Jobs which are
> created after the global config is set. I'm finding that I actually have to
> enable the plugin on each job in order to have the opportunity to apply my
> global settings. In this particular instance, its a Publisher. I wanted to
> just create a Job and not have to click anything if the global default was
> acceptable.
>
> Is there some way that I can enable these extra BuildSteps by default? The
> only way I have found to do this that might get me there is to add a
> JobListener that listens for new Projects, and when it notices them, it
> would add the BuildSteps using the global settings as a template. I haven't
> actually figured what I need to add to the Project to do this, but this
> would be the general approach I'd take.
>
> Is there a better way?
>


--
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi@xxxxxxx

-- 

- Eric