Ticket #14 (new enhancement)

Opened 2 years ago

Last modified 1 year ago

master.cfg.d

Reported by: warner Assigned to: warner
Priority: minor Milestone: 0.8.0
Component: configuration Version:
Keywords: Cc:

Description

Rob Helmer pointed out that it could be awfully handy to split the master.cfg file out into a directory of separate files, not unlike Debian does for a lot of configuration. If the buildmaster doesn't see BASEDIR/master.cfg, but it does see BASEDIR/master.cfg.d , then it should look at a well-defined set of files inside that directory (see debian's /bin/run-parts for ideas) and eval all of them into the same namespace.

issues:

  • do the multiple dots in "master.cfg.d" cause problems on windows filesystems? does anyone really care?
  • what happens if you have both a master.cfg and a master.cfg.d ?

Change History

02/10/07 11:37:41 changed by rhelmer

Maybe have the dir just be "config.d"?

05/12/07 13:03:14 changed by warner

discussion on the mailing list made me aware of a small issue, if folks want to use this as a replacement for importing local modules from master.cfg . All the classes defined in master.cfg or the other foo.d/* files that get exec'ed will get a new identity upon each reconfigure, which will cause spurious activity.

(basically the buildmaster will think that you've changed all the Builders that reference those classes, or the Schedulers or ChangeSources?)

hmm, but these days that's not as much of a problem as it used to be. Since the addition of Builder.consumeTheSoulOfYourPredecessor (boy was I punchy when I wrote that one), replacing a Builder with an exact copy doesn't actually lose any information. Schedulers will lose any builds that were pending (waiting for the tree-stable-timer to fire), but conceivably we could create a ChangeSource.consumeTheSoulOfYourPredecessor method. Some of the status plugins could be affected (if you had a subclass of the IRC bot, it would probably disconnect and reconnect on each reconfig).

On the other other hand, admins would always have the option of putting their subclasses in separate modules and importing those from the master.cfg.d/* files, giving them exactly the same behavior as the current code, in which they'd either have to use reload() or completely restart the buildmaster to trigger those changes.

10/01/07 13:04:13 changed by warner

  • milestone set to 0.8.0.