Skip to content

Cascading Projects released as BETA

October 28, 2011

Have you ever despaired at having to update multiple Hudson jobs when you need to change properties? Perhaps you use templates or copy jobs to try and alleviate this at job creation, but what about further down the road? What you’ve dreamed of is the ability to have some kind of inheritance of properties throughout the life of jobs.

Dream no longer! Hudson has released a beta of its new Cascading Projects feature. Now you can define a project with a cascading parent and have a child project derive its configurable properties from its parent.

Cascading Projects is not a template, you can configure a job to inherit properties from its parent, whilst overriding those that need to be changed or later reverted back to the parent. Any changes you make to the properties in a parent will cascade down through the child jobs that inherit that property.

Take the example here.  Job3.2 will inherit its properties from Job3.1, which in turn inherits from Job3 and so on.

But what if Job3 overrides a property it inherits from Job1? That change will cascade down to Job3.1 and Job3.2

If the the same property is subsequently changed in Job1 then the change will cascade down to Job2 but the override in Job3 will stay in place for that job and its children

You use the project config page to select an existing saved project to inherit from. Any project can be used as the parent, but you cannot create a cyclic inheritance. Most of the properties are cascadable and if the parent contains Builders, Publishers or Triggers they will be merged with the child.

So what kinds of projects might benefit from Cascading Projects? A few of the most common examples include updating email notification lists, project-based security, reports published locations and polling the source repository.

This new feature comes from a request from the community in HUDSON-3157 and is an example of the work that the Hudson team is engaging in along with bug fixing and all the work associated with the entry to the Eclipse Foundation as detailed in a previous post.

The details of the implementation and the full list of cascadable properties are detailed on the wiki. As with any beta release, your feedback is greatly appreciated. The final release is scheduled for mid-November and we will endeavour to address any feedback and make updates to the feature before then.

You can download the Hudson 2.2.0-Beta war file here. Please be sure to test this with a copy of your production Hudson home. The implementation adds some additional elements to the project configuration XML which will not be recognized by Hudson 2.1.x and previous.

Susan Duncan

About these ads

From → New Features

5 Comments
  1. Chris Quenelle permalink

    I have a question about cascading jobs. If I use scripts (“Execute Shell”) as a build step in a parent job, will I be able to apply an additional script to a descendant job? Or is my only option to completely override the script in the parent job?

  2. When you inherit from the base project the script step will be available in the new project and you can obviously overwrite it. Or you can leave it in place and simply add an extra step.
    The inheritance part of the cascading project relates to the properties rather than the additional build steps

    • Chris Quenelle permalink

      I’m using a version of Hudson that doesn’t support multiple script steps, so I might have been a little confused. I understood your reply up until the last sentence. It sounds like you are saying that build steps are inherited, and then you say they are not?

      • OK it’s confusing because when you use a cascading project to provides both a inheritance model with respect to the job properties, but it also provides a template for the rest of the job. So if the job that you cascade from has a specific step, then that step will be cloned into the new job. However, subsequent changes in that step in the base job will not propagate through to the downstream job. Property changes however will propagate.

      • Chris Quenelle permalink

        Ah yes! I see what you mean about “inheritance model” and “template”. Thanks for explaining. We depend heavily on short but non-trivial scripts. It would be useful to share common script steps between jobs somehow. Either by inheriting them or by defining them at the top level with names. For now, I keep these as external script files accessed over NFS, but I’d prefer to embed them inside Hudson config.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,351 other followers

%d bloggers like this: