[Bf-committers] Discussion of a Blender Compile Farm

[Timothy Baldridge]

     A little over a week ago I created a automated compile farm. It's
gone through a fair amount of testing, and had a fair amount of
positive response so far. Below is are the plans for my rewrite of the
scripts I'm using. I'd love to discuss these plans, but it'll have to
be on this mailing list since the IRC meetings are at a totally bad
time for me (CST).

For those interested, the Alpha forum thread is available here:
http://blenderartists.org/forum/showthread.php?t=114603


Timothy Baldridge


Goals for Blender Compile Farm:

    * To provide an automated-cross platform way for creating builds
off of the SVN trunk or any desired branches


Benefits of having the Farm:

    * Users can try out new features on a regular basis instead of
waiting on new releases
    * Developers can get "instant" feedback if their commits break
builds on other platforms
    * Streamlined releases by allowing beta testers more time to find
bugs, and insuring that the program always builds correctly on common
platforms.
    * More beta testing of SSE optimized builds.


Requested Services/Resources from the Blender Foundation:

    * Web server space for builds (approx 8MB per platform per build
type (SSE, SSE2, etc)
    * Two mailing lists for build logs one for errors, and one for
successful logs.
    * Some sort of pop3 account (read the notes below for info).
Currently a Gmail pop account is used.
    * Inclusion of the client-side script into the main SVN trunk


Implementation for the Server Side scripts:

    * Script Generates a Build tag from the OS name and the build
options (e.g. Windows-SSE2-SVN, or Linux-AMD64-SSE3-SVN)

    * Do{

          * Check pop email that is subscribed to Blender-CVS
          * Extract the revision number from the top e-mail
          * Is the revision higher than the revision on the local disk?
          * If not, sleep for a minute then jump back to "Do{"
          * Update local SVN copy
          * Build using scons
          * Zip the contents of the install folder
          * Upload the file to the web server in the folder
corresponding to the build tag
          * Upload the revision.txt file to the web server
          * Send a build log to admins

    * } Loop


Current Implementation of Client Side update:
    Yes, this is a convoluted way of doing it, but on Windows you
can't overwrite a .exe that is running. This should get around that
limitation.

    * Save the current .blend to ./autosave.blend

    * Download Available build options from web server

    * Present GUI with options

    * Does revision.txt exist?

          * If so, is the online version newer?
                * If not, exit

    * Download blender.zip

    * Unzip into the ./update dir

    * execlp ./update/blender.exe and have it run the update script.


    In the update script:

    * Copy the contents of the current directory up one level

    * execlp ../blender.exe and have it run the cleanup script.


    In the cleanup script:

    * Delete the contents of the ./update directory

    * execlp blender.exe and load the autosave.blend