[Release] Some Bob docs

Keith Hodges keith_hodges at yahoo.co.uk
Sun Oct 26 00:53:31 UTC 2008


Some introductory docs

Keith

=======
*
Bob the Builder*
*/
Your Build is defined as a Class/*

To add your own 'Build' process to Bob, create a subclass of BobBuild,
with your process defined as a SakeTask returned from the class method
#build. When Bob starts his work in BobBuild-c-#taskMain, he collects
all of these tasks, and sorts them according to their dependencies.
/*
Your build can depend upon other builds*/

So your build can specify which other builds it depends upon, for example:

BobBuildMyWebServer-#build

^ self define: [ :task |
    task dependsOn: { BobBuildSeasideOneClick build }.

    .... ... ... ].
/*
Repositories are watched and builds run when changes are spotted*/

Sake-Scheduler is used to run periodic tasks. These tasks can do many
useful things, as well as running #taskMain. Scheduled tasks are used to:
 
1. Periodically collect data that either Bob/users may need in their
work (e.g. BobPeriodicallyReadMantis )
2. Periodically update the Bob server image with the latest code from
contributors (e.g. BobPeriodicallyWatchRepositories )

You can add your own periodic tasks by subclassing ScheduledTask,
however some tasks are designed to be extended, by adding (extension)
instance methods.

e.g. BobPeriodicallyWatchRepositories-#taskWatchPackages (watches the
squeaksource Packages repository for updates)
if you wish to invoke bob following an update to your repository this
example shows how.

BobPeriodicallyWatchRepositories >> #taskWatchTasks

^ SakeTask     checkUrl: 'http://www.squeaksource.com/Tasks/feed.rss'
            onChanged: [ Installer sake install: 'Tasks'.
                         BobBuild taskMain run. ].
    /*
Configuration*/

Your build process 'task' is defined on the class side of your Build
class. If your task has a number of "const" parameters that configure
the task, these should also be defined on the class side. For example,
the location of a working directory would be returned from #configWorkingDir

/*Metadata - build numbers etc*/

The metadata for each Build task is specified on the instance side of
the class, e.g. #build0001, #build0002.
Your task definition in #build is automatically uses the most recent
metadata method.

example metadata:

MyBuild>>#build0001

    info name: 'Squeak3.11-basic'.
    info moniker: '311'.
    info codeName: 'Kipper'.
    info by: 'kph'.
    info image: 'bzr://bzr.warwick.st/squeak/3.10'.
    info candidate: false.
    info release: false.
    info overwrite: true.
    info comment: 'testing'.
        

/*Only build if necessary*/

It is very important that your build only runs when absolutely
necessary. If your build is manually invoked by an increment in build
number (i.e. info overwrite: false) then the existence of the output
directory with that build number is enough to determine that the build
has already been run.

If your build is automatically invoked by updates to particular
repositories, then the versions of those packages need to be recorded in
the metadata. The metadata is written to a file in the output directory.
Subsequent builds should compare the current metadata with that in the
file to see whether the build needs to be re-run.

If your build is a derivative of a released product, then you only need
to build if the dependant has #info release = true.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/release/attachments/20081026/1acbff2a/attachment.htm


More information about the Release mailing list