[Buildbot-devel] Setup of client's environment from client

Trask trask at techsoft3d.com
Thu May 19 19:32:51 UTC 2011


On 05/19/2011 12:17 PM, Philippe McLean wrote:
> what are some examples of things you need to configure in the environment?
>
> On Thu, May 19, 2011 at 12:14 PM, Trask <trask at techsoft3d.com
> <mailto:trask at techsoft3d.com>> wrote:
>
>
>     * Buildbot: 0.8.3p1
>     * Twisted: 10.1.0
>     * Jinja: 2.5.2
>     * Python: 2.6.6 (r266:84292, Sep 15 2010, 16:22:56) [GCC 4.4.5]
>     * Buildmaster platform: linux2
>
>     In order to follow best practices I am working to capture all
>     configuration information within the source itself so that it is
>     versioned, tagged, etc right along with everything else.
>
>     One particular part has been giving me problems: how to set up the slave
>     environment based upon code it has checked out in a buildstep. If I set
>     everything in master.cfg on the buildmaster, everything works fine,
>     however that does not capture the configuration data within the
>     ever-changing source.
>
>     My original idea was to run a "setup-environment.py" script which would
>     always be run prior to the other build steps. This doesn't work because
>     it is only modifying the environment for it's own process. Even if it
>     did modify the global environment that is not ideal due to likely
>     collisions with simultaneous usage of the machine.
>
>     My next attempt was to encapsulate every command within a "setup-env"
>     script. You pass the command to run to the script as an argument and
>     then it sets up the environment and then runs the command. I've gotten
>     this to work to a degree but is clearly not the proper way to accomplish
>     what I am trying to do.
>
>     BuildProperties seems promising but I haven't thought of a clean way to
>     use them. I could imagine running the "setup-env" script, having it
>     spit out the proper environment settings to use and then using
>     "SetProperty" with a custom function to set Properties which THEN get
>     translated into environment settings on the client. Hmmph.
>
>     This seems like an issue that would crop up for a lot of people so I am
>     interested in hearing how other people have solved this.
>
>     Thanks for any help!
>
>     ~Trask
>

Primarily it is 3rd party SDK locations, such as:

MAXSDK_2011_INSTALL_DIR=C:\build\resources\3dsmax\3dsmax2011\maxsdk
PARASOLID_INSTALL_DIR=C:\build\resources\parasolid\parasolid_23.0.156\intel_nt\base

Most everything else that has traditionally used environment variables 
could be provided on the command line to the build scripts.  These SDK 
dirs, however, need to be configured in the environment for the builds 
to work.

There are about 15 like this which each vary slightly upon the compiler 
and 32 vs. 64 bit build.  Despite this variance, *these* will be the 
same on any machine that does that same build.  However, there are other 
directories that will always be different on a per-machine basis.

I *could* do all of this setup on the master since the location of 
everything is planned, but then that would mean I would be keeping 
configuration data separate from the source itself.

This isn't necessarily wrong but I have felt like the best long-term 
solution is to keep the configuration with the source.  I guess this 
will always have the flaw of the buildbot source moving on as well... 
Like: in 3 years if I want to build today's source, will I use "Buildbot 
2014" to build it or use a versioned install of Buildbot from May 19th 
2011?  Does anyone else plan for this sort of possibility?

~Trask




More information about the devel mailing list