Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-3157

Feature request: cascading project settings

    Details

    • Type: New Feature
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
      None
    • Environment:
      Platform: All, OS: All

      Description

      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.

        Issue Links

          Activity

          Hide
          jglick Jesse Glick added a comment -

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

          Show
          jglick Jesse Glick added a comment - Unfortunately creating a GUI to edit heritable settings can be tricky.
          Hide
          huybrechts huybrechts added a comment -

          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.

          Show
          huybrechts huybrechts added a comment - 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.
          Hide
          stormcloud stormcloud added a comment -

          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.

          Show
          stormcloud stormcloud added a comment - 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.
          Hide
          blidgey blidgey added a comment -

          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.

          Show
          blidgey blidgey added a comment - 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.
          Hide
          cristalp cristalp added a comment -
              • Issue 2419 has been marked as a duplicate of this issue. ***
          Show
          cristalp cristalp added a comment - Issue 2419 has been marked as a duplicate of this issue. ***
          Hide
          cristalp cristalp added a comment -

          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.

          Show
          cristalp cristalp added a comment - 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.
          Hide
          mdonohue mdonohue added a comment -
              • Issue 3314 has been marked as a duplicate of this issue. ***
          Show
          mdonohue mdonohue added a comment - Issue 3314 has been marked as a duplicate of this issue. ***
          Hide
          eguess74 eguess74 added a comment -

          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:
          <project>
          <property name="projectname" value="version"/>...
          <import file="../common_config.xml"/>
          </project>
          When the common_config.xml can be something like:
          <project>
          ....
          <customWorkspace>C:\Ivy\apache-ivy-2.0.0\src\example\multi-
          project\projects\$

          {projectname}

          </customWorkspace>
          <project/>
          So it actually comes down to 2 things
          Importing XML files
          custom properties support

          Does it makes sense?

          Show
          eguess74 eguess74 added a comment - 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: <project> <property name="projectname" value="version"/>... <import file="../common_config.xml"/> </project> When the common_config.xml can be something like: <project> .... <customWorkspace>C:\Ivy\apache-ivy-2.0.0\src\example\multi- project\projects\$ {projectname} </customWorkspace> <project/> So it actually comes down to 2 things Importing XML files custom properties support Does it makes sense?
          Hide
          mdonohue mdonohue added a comment -
              • Issue 2971 has been marked as a duplicate of this issue. ***
          Show
          mdonohue mdonohue added a comment - Issue 2971 has been marked as a duplicate of this issue. ***
          Hide
          jotimail jotimail added a comment -

          cc me please

          Show
          jotimail jotimail added a comment - cc me please
          Hide
          mdonohue mdonohue added a comment -
              • Issue 346 has been marked as a duplicate of this issue. ***
          Show
          mdonohue mdonohue added a comment - Issue 346 has been marked as a duplicate of this issue. ***
          Hide
          mdonohue mdonohue added a comment -
              • Issue 4516 has been marked as a duplicate of this issue. ***
          Show
          mdonohue mdonohue added a comment - Issue 4516 has been marked as a duplicate of this issue. ***
          Hide
          lacostej lacostej added a comment -

          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?

          Show
          lacostej lacostej added a comment - 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?
          Hide
          mdonohue mdonohue added a comment -

          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.

          Show
          mdonohue mdonohue added a comment - 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.
          Hide
          stormcloud stormcloud added a comment -

          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

          Show
          stormcloud stormcloud added a comment - 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
          Hide
          mdonohue mdonohue added a comment -

          Sounds good to me

          Show
          mdonohue mdonohue added a comment - Sounds good to me
          Hide
          stormcloud stormcloud added a comment -

          Thanks

          Show
          stormcloud stormcloud added a comment - Thanks
          Hide
          akostadinov akostadinov added a comment -

          +1 to stormcloud's description

          Show
          akostadinov akostadinov added a comment - +1 to stormcloud's description
          Hide
          javadude Carl Quinn added a comment -

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

          Show
          javadude Carl Quinn added a comment - +1 to stormcloud's description as well. I would love this feature!
          Hide
          deccico deccico added a comment -

          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.

          Show
          deccico deccico added a comment - 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.
          Hide
          johnstosh John Muczynski added a comment -

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

          Show
          johnstosh John Muczynski added a comment - It would really help me if you cascade the "Invoke Ant" part of the "Build" section of the configuration.
          Hide
          dougborg Doug Borg added a comment -

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

          Any chance of porting this feature to jenkins?

          Show
          dougborg Doug Borg added a comment - This has been implemented in Hudson: http://issues.hudson-ci.org/browse/HUDSON-3157 Any chance of porting this feature to jenkins?
          Hide
          bshappee Bart Shappee added a comment -

          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.

          Show
          bshappee Bart Shappee added a comment - 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.
          Hide
          babazs Torresz Daniel added a comment - - edited

          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!

          Show
          babazs Torresz Daniel added a comment - - edited 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!
          Hide
          idapperdanman David Ishee added a comment -

          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

          Show
          idapperdanman David Ishee added a comment - 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
          Hide
          philrumble Phil Rumble added a comment -

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

          Show
          philrumble Phil Rumble added a comment - Is this ever going to be ported from Hudson to Jenkins?
          Hide
          zofren Zofren Kopat added a comment -

          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.

          Show
          zofren Zofren Kopat added a comment - 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.
          Hide
          rheostat Mike Smith added a comment -

          Any updates on this one?

          Show
          rheostat Mike Smith added a comment - Any updates on this one?
          Hide
          imakowski Ireneusz Makowski added a comment -

          Do you plan to merge this feature from Hudson?

          Show
          imakowski Ireneusz Makowski added a comment - Do you plan to merge this feature from Hudson?
          Hide
          ldenanot Laurent Denanot added a comment -

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

          Show
          ldenanot Laurent Denanot added a comment - 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...
          Hide
          edrandall Ed Randall added a comment - - edited

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

          Show
          edrandall Ed Randall added a comment - - edited The "Inheritance Plugin" is not perfect but seems to mostly solve this problem. https://wiki.jenkins-ci.org/display/JENKINS/inheritance-plugin

            People

            • Assignee:
              Unassigned
              Reporter:
              stormcloud stormcloud
            • Votes:
              154 Vote for this issue
              Watchers:
              93 Start watching this issue

              Dates

              • Created:
                Updated: