Hard-coded build workflow ------------------------- Currently in AutoBuild, the flow of events is hard-coded in a single file - AutoBuild.pm. This flow is roughly: * read in configuration * obtain lock file or exit * create directories / setup environment * check out source code from repositories * clean old package directories * clean build root(s) * build each module and record its artifacts * run each output module * release lock file There are two problems with this approach. First, AutoBuild.pm becomes large and cluttered. Second, and more significantly, there is no easy way to change the workflow. For example, if you wanted to add a notification service that sent out email before the builds started, you would have to hack AutoBuild.pm. In a sense, Output modules address this problem in that they let you add arbitrary functionality, but you have little power in deciding when they are run, and they must act in isolation from other modules. Dan Berrange <berrange@redhat.com> came up with the idea of generic stages. A stage would be any set of actions that are performed as part of the AutoBuild process. The set of stages and their configurations would be configurable on a per-instance basis of AutoBuild. This would give administrators much more flexibility in how/when/which actions are performed. There would be a set of properties shared by any stage instance. For example, each stage would have a run() method which return success or failure[0]. Additionally, each stage would be marked as critical or non-critical. The distinction is that a critical stage failing will cause AutoBuild to stop, while it will continue to run despite a non-critical stage failing. Another possible property common to stages is dependencies. However, it is not clear that explicit dependencies would be better than just using the order of the stages as listed in the configuration. The refactoring of the current AutoBuild code to use this concept of stages would be relatively straight-forward. A number of the existing classes (i.e. repositories and output modules) would be ported to be stages. Also, the logic in AutoBuild.pm would be split out into new stage classes, probably corresponding very closely to the steps that were listed above.
