How to enable a publisher by default?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

How to enable a publisher by default?

Eric Crahen-3
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?

--

- Eric
Reply | Threaded
Open this post in threaded view
|

Re: How to enable a publisher by default?

Eric Crahen-3
I guess I can call addPublisher() from a JobListener, but still - is there another way?

On 1/28/07, Eric Crahen <[hidden email]> 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?

--

- Eric



--

- Eric
Reply | Threaded
Open this post in threaded view
|

Re: How to enable a publisher by default?

Eric Crahen-3
Nope, unprotected the addPublisher method and calling directly doesn't work

On 1/28/07, Eric Crahen <[hidden email]> wrote:
I guess I can call addPublisher() from a JobListener, but still - is there another way?


On 1/28/07, Eric Crahen <[hidden email]> 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?

--

- Eric



--

- Eric



--

- Eric
Reply | Threaded
Open this post in threaded view
|

Re: How to enable a publisher by default?

Kohsuke Kawaguchi-2
In reply to this post by Eric Crahen-3

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                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to enable a publisher by default?

Eric Crahen-3
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 artifacts 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 <[hidden email]> 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                   [hidden email]





--

- Eric
Reply | Threaded
Open this post in threaded view
|

Re: How to enable a publisher by default?

Kohsuke Kawaguchi-2
Eric Crahen wrote:
> 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.

OK, so in its core functionality it's really not that different from,
say, Emma plugin or JUnit reporter.

> 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 artifacts could be another I'd explore shortly after that.
I see. To me this sounds like somewhat orthogonal to the plugin itself.

That is, I think your plugins would be more reusable to other people if
they don't have built-in knowledge about the policy of your development
team. For example, some of the jobs that I run on my Hudson would very
much like to use FindBugs plugin, but we don't have the policy like yours.

What you are describing makes sense too --- when you have a large number
of "similar" projects, it should be easy to configure them in a similar
way, without going through each project separately. But my point is that
such thing shouldn't really be baked into your plugin, because it should
be applicable to any setting, like log rotation, fingerprinting, IRC, etc.

This "maintaining a large number of projects with similar settings"
support is one of the obvious things that Hudson should do better, but I
haven't found a good answer that brings simplicity.

Perhaps one approach could be for you to extend Project and override the
configuration portion. It's still a Project, so it will behave like it,
but you can take over the configuration screen completely and let users
configure just small portion of parameters.

For example, your team might be using a standard directory layout
convention, and perhaps you won't have to make the javadoc directory
configurable. Or you might want to automatically enable IRC notification
to the channel name that can be automatically derived from the job name,
etc. All the jobs might use the same CVS server, and if so you can
eliminate the SCM configuration completely except perhaps the module
name and the branch name.

In this way, you should be able to eliminate a considerable number of
options from the configuration screen. Less form fields = simpler!

The user would then have to just choose "our team's project" (or
something) when they create a new job, and they'll see a much simpler
config screen and Hudson will behave as if it understands your team's style.

We'll probably need to refactor Project object a bit so that you can
take over the configuration more easily, but I believe this is a
feasible approach.


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

I wholeheartedly agree that we engineers should be lazy and shouldn't be
forced to read documentation :-)


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

I hope I provided a better alternative above, but if you still want to
just enable a publisher by default, we can talk about getting the
addPublisher/save work.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to enable a publisher by default?

Eric Crahen-3
On 1/29/07, Kohsuke Kawaguchi <[hidden email]> wrote:

That is, I think your plugins would be more reusable to other people if
they don't have built-in knowledge about the policy of your development
team. For example, some of the jobs that I run on my Hudson would very
much like to use FindBugs plugin, but we don't have the policy like yours.

What you are describing makes sense too --- when you have a large number
of "similar" projects, it should be easy to configure them in a similar
way, without going through each project separately. But my point is that
such thing shouldn't really be baked into your plugin, because it should
be applicable to any setting, like log rotation, fingerprinting, IRC, etc.

I agree

This "maintaining a large number of projects with similar settings"
support is one of the obvious things that Hudson should do better, but I
haven't found a good answer that brings simplicity.

Perhaps one approach could be for you to extend Project and override the
configuration portion. It's still a Project, so it will behave like it,
but you can take over the configuration screen completely and let users
configure just small portion of parameters.

For example, your team might be using a standard directory layout
convention, and perhaps you won't have to make the javadoc directory
configurable. Or you might want to automatically enable IRC notification
to the channel name that can be automatically derived from the job name,
etc. All the jobs might use the same CVS server, and if so you can
eliminate the SCM configuration completely except perhaps the module
name and the branch name.

In this way, you should be able to eliminate a considerable number of
options from the configuration screen. Less form fields = simpler!

I like this idea. I think I should be able to make a generic plugin with no built in knowledge that would be useful for everyone, and then just extend it to produce the custom Project type you described to satisfy my particular use case which is more specific to my organization. That way everyone  wins ;)

I'll chew on this for a while. I'm keeping myself busy figuring out the ins and outs of jelly for the first time. Once I have the generic/simpler plugin done, I'll revist this thread and give an update of any progress I made with this sort of approach should anyone else watching be interested in how well that works out.


--

- Eric
Reply | Threaded
Open this post in threaded view
|

Re: How to enable a publisher by default?

Kohsuke Kawaguchi-2
Eric Crahen wrote:

> I like this idea. I think I should be able to make a generic plugin with no
> built in knowledge that would be useful for everyone, and then just extend
> it to produce the custom Project type you described to satisfy my particular
> use case which is more specific to my organization. That way everyone  wins
> ;)
>
> I'll chew on this for a while. I'm keeping myself busy figuring out the ins
> and outs of jelly for the first time. Once I have the generic/simpler plugin
> done, I'll revist this thread and give an update of any progress I made with
> this sort of approach should anyone else watching be interested in how well
> that works out.
Sounds good.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

smime.p7s (4K) Download Attachment