[JENKINS-3157] Feature request: cascading project settings

[timja]

I don't know how difficult this would be to implement, but it would be handy to
have a user-definable set of "default" project settings that cascade into the
setting for real projects. Real project can override the cascaded properties as
they see fit.

For example, almost every one of my projects uses the Sventon repository
browser. When it is enabled they all point to the same URL and the same
repository instance. When I start a new project I have to set up Sventon with
these properties (with out typos). It would be easier to have the project
automatically aquire these setting from the cascade.

If at some later date I was to move Sventon to a new location I would like to be
able to change the settings in one place (the top of the cascade) and have all
the projects pick up the change. Currently I would have to edit all of the
projects individually (with out making mistakes).

In the few cases where I do not need the cascaded setting I would like to be
able to override them in the individual projects.

I've used Sventon in my examples, but in practice I always publish JavaDocs and
Junit reports to the same location (relative to the project). I always pick up
the Cobertura coverage report from the same location. I poll the source
repository at the same time schedule. I use the same project-based security for
most of my projects (there are a couple of projects where I need to give
people less access rights).

More importantly I always want the "Trigger even if build is unstable" setting
to be turned on for all projects (I want to see how unstable builds effect down
stream projects). However, we only get this option when we assign the first down
stream project and it's default is off. Since I'm usually concerned with
configuring the down stream project at this point it's easy to forget to set
this flag.

---

Originally reported by stormcloud, imported from: Feature request: cascading project settings

• status: Open
• priority: Major
• resolution: Unresolved
• imported: 2022/01/10

[timja]

jglick:

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

[timja]

huybrechts:

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.

[timja]

stormcloud:

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.

[timja]

blidgey:

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.

[timja]

cristalp:

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

[timja]

cristalp:

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.

[timja]

mdonohue:

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

[timja]

eguess74:

i have copied from #3314.
It is probably not the best solution - not GUI based. But probably easier to
implement because it exists in ANT and CC.
I was thinking about storing common configuration in common_config.xml and then
import it into the config.xml of the specific project. So it could look like:

...


When the common_config.xml can be something like:

....
C:\Ivy\apache-ivy-2.0.0\src\example\multi-
project\projects\${projectname}

So it actually comes down to 2 things
Importing XML files
custom properties support

Does it makes sense?

[timja]

mdonohue:

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

[timja]

jotimail:

cc me please

[timja]

mdonohue:

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

[timja]

mdonohue:

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

[timja]

lacostej:

I helped implementing the templating feature in CruiseControl.

http://cruisecontrol.sourceforge.net/main/plugins.html#preconfiguration

I've not looked at the hudson's internal enough but maybe something similar could be implemented in hudson?

[timja]

mdonohue:

The constraint for Hudson is getting the UI right. In contrast to CruiseControl, Hudson users never need to edit XML files when setting up jobs - all configuration is done through the web UI. This is a feature we want to maintain going forward.

[timja]

stormcloud:

As a matter of interest, is there some thing wrong with the suggestion for the GUI I described on 27/Feb/09? Basically:

1) Setting up cascade would be done with exactly the same GUI we currently currently use for defining a project

2) When creating a new project we get an extra option to create from cascade. Hudson will could provide a list of available cascades in a drop down

3) When filling in a cascaded project there could be a check box on the left hand side to enable/disable the cascade for each setting. If the cascade is enabled the GUI widgets to the right will show the cascaded values, but will be greyed out. If the cascade is disabled for that setting, the GUI widgets are available for the user to modify.

The important thing in step 3 is that the greyed out values are always the current cascade settings, and not the values when the project was created. That is we reference the current values, rather then copy them

[timja]

mdonohue:

Sounds good to me

[timja]

stormcloud:

Thanks

[timja]

akostadinov:

+1 to stormcloud's description

[timja]

javadude:

+1 to stormcloud's description as well. I would love this feature!

[timja]

deccico:

Maybe a similar behavior could be achieved by extending the "Configuration Slicing" plugin. Right now you can propagate some configurations like "Time trigger" and disabling a job, but it would be great to set / modify one or more parameters.

[timja]

johnstosh:

It would really help me if you cascade the "Invoke Ant" part of the "Build" section of the configuration.

[timja]

dougborg:

This has been implemented in Hudson:
http://issues.hudson-ci.org/browse/HUDSON-3157

Any chance of porting this feature to jenkins?

[timja]

bshappee:

For the projects I'm working this feature would be exceptionally useful, for many different builds were there are just slight tweaks to the build & test cycle to cover all variants.

[timja]

babazs:

We should decide between Hudson and Jenkins and we extremely need this feature. So I'd like to ask that will this feature implemented in the near future in Jenkins? Thanks for your answer!

[timja]

idapperdanman:

I rely on this in my Hudson installation. Looks like I can't upgrade to Jenkins as a "drop in replacement" for Hudson according to https://wiki.jenkins-ci.org/display/JENKINS/Upgrading+from+Hudson+to+Jenkins

[timja]

philrumble:

Is this ever going to be ported from Hudson to Jenkins?

[timja]

zofren:

I really need this feature. I have nearly 200 jobs and I can't manage to update specific cobertura threshold, defined at the company level and recently updated. And this is only an example of planned modifications.

[timja]

rheostat:

Any updates on this one?

[timja]

imakowski:

Do you plan to merge this feature from Hudson?

[timja]

ldenanot:

Seeing this issue has been opened and unassigned for more than 4 years , I highly doubt that the cascading project feature added by Oracle in Hudson will ever be ported to the Jenkins core or as a free plugin.

In fact, an equivalent feature has been available since 2011 as part of the Jenkins Enterprise offering by Cloudbees, and is known as the 'Jenkins Enterprise Templates plugin':
See http://kohsuke.org/2011/11/15/introducing-template-plugin/

This commercial offering also benefits from the complementary 'Folders' and 'Role based access security' plugins that greatly simplify the administration of large Jenkins installations with hundreds or more jobs.

What really is a pity is that, although the 'Folders' plugin is now available with a free licence (see http://www.cloudbees.com/press-room/cloudbees-donates-five-plugins-jenkins-community.cb), the 'Templates' plugin is not.

With a templating/cascading configuration feature being such a basic requirement of a CI server, IMHO it really should be included in the core Jenkins, along with the Folders plugin as well for that matter, and possibly the Role-based access plugin too ...

I mean, if you look at good old Apache Continuum, it's been featuring Project groups, Build definitions and common build schedules, and project-based security from the beginning...

[timja]

edrandall:

The "Inheritance Plugin" is not perfect but seems to mostly solve this problem.
https://wiki.jenkins-ci.org/display/JENKINS/inheritance-plugin

[timja]

aidalgol:

The Inheritance plugin hasn't had a release since 2014, and does not work with SCM polling.

Polling will only work for many SCM plug-ins, if the SCM property or its polling property is enabled is defined on a job itself, but not if it's inherited. We are investigating whether this can be fixed without having to alter the code of the SCM plug-ins themselves.

So it is not a viable option for many users.

[timja]

[Originally duplicated by: JENKINS-3314]

[timja]

[Originally duplicated by: JENKINS-2419]

[timja]

[Originally duplicated by: JENKINS-2971]

[timja]

[Originally duplicated by: JENKINS-4516]

[timja]

[Originally related to: JENKINS-14185]