Unfortunately creating a GUI to edit heritable settings can be tricky.

The template-project plugin can do part of this.
It doesn't do repository browsers yet, but that certainly is a reasonable
extension. Have a look at it, see if it meets your needs and feel free to raise
specific feature request against that plugin.

What I'm suggesting is more then a template (although that would be a good
start). The important difference is that the project doesn't copy the default
values, it references back to them. If the values in the template are changed
then they are reflected in all projects that have already been derived from
them. I can see a couple of uses for this:

1) Migrating resources such as the Sventon URLs.
2) Updating e-mail notification lists if a project leader were to leave.

Ok, these are reasonably trivial to change by editing the raw XML, but something
like a global change to the project security settings or code coverage
requirements is no so easy to implement by editing raw html.

From a GUI POV I had though that setting up the cascade would be just like
editing a regular project. The user would be able to set values exactly as they
do now.

To use the cascade the project would have an extra property to say which cascade
they are taking values from. Then the project would be given an extra option to
use cascaded value for each of the setting or over ride it with a specific
value. This could be done with a check box to enable or disable the options. It
would probably be a good idea if the cascade were the default.

I don't think it would be a good idea to allow user to change the cascade while
editing the derived project though. That would be far to complex for GUI, and
probably the user as well.

An interesting question would be how many levels of cascade would be allowed
(can you define a cascade based upon a another cascade?). Personally I think
that would be over kill.

Anyway that's just my two cent.

We have created a disabled project called ProjectTemplate and any new projects
created are copies of that rather than new ones in their own right.

But as we are increasing our usage of Hudson then we are looking to turn on
things like Cobertura or Checkstyle report publishing, and applying that to all
the projects is a pain.

Perhaps one approach would be to have a configuration set that can be applied to
a project. Configuration sets would then be a centrally managed config that can
be edited in one place and applied rather than implementing a hierarchy. I
suppose this is analogous to the config in CruiseControl where you can define a
project template in the XML, and changes made to that are applied to all the
projects for that definition.

• • • Issue 2419 has been marked as a duplicate of this issue. ***

Copied discussion from issue 2419

I think that normally, companies define certain quality goals and use Hudson's
plugins to achieve them. However, defining the same configuration over and over
again for every job is something that IMHO needs to be fixed.
One possible solution would be a "master" job which is configured once. All
dependent jobs can then override any configuration, if they want to.
As far as I can see (being new to Hudson), this has been requested on the
mailing list before, but I didn't find any enhancement request in here.

------- Additional comments from cristalp Fri Nov 14 12:19:50 +0000 2008 -------

See also the discussion on
http://www.nabble.com/Features-common-to-all-jobs-td20350398.html

------- Additional comments from jeffjensen Sun Feb 8 18:12:51 +0000 2009 -------

I agree. We should be able to specify defaults for all project and plugin
settings, and only need to change them per project configuration as necessary.
This saves on initial setup and maintenance time.

• • • Issue 3314 has been marked as a duplicate of this issue. ***