Remake of the Distributed Build System
- Faster builds without sacrificing reliability
- Stats per server
- Build clients (BC) connect to server
- Support cross-compiled win32 sim builds
- Upgrade ability from the master to the clients == keep local configs separate from the main build script
Would be nice
- Use persistent SSH sessions instead of opening and closing multiple per build
- Support rbutil builds?
- Support manual builds?
Things we want (to consider) in the new build system.
A Speculative parallel builds
All BCs pick an unfinished build as long as not all builds are done. This means that towards the end, more than one BC will build specific builds and the fastest one will be used. This also means that the slower BCs need to be told to kill their build when another BC already completed an upload.
B Allow More than One Admin
We need to allow for a multitude of admins to be able to allow new clients to join the fun.
C Prioritize builds recently done on same BC
Allow BCs to ask for "preferred builds" so that they can ask for builds it recently did, and thus make better use of ccache.
D Allow updates from server
One problem of the existing solution is that we allow a bit too much configuration of the main build script in a way that it made it impossible for us to upgrade the remote builds scripts.
E Auto-ranking of build clients
Use build and uploads speeds (over time) for particular BCs to calculate which BC that ought to get which builds. May of course conflict with (C)
F Uploading in the background
Make the BC start the next build while uploading the previous one.
Each client keeps a control channel open against the build server, for commands and information.
Control channel is a SSL connection with unique certificate for each build client
> BUILD [build-id] [conf-options] [revision] [zip] [multithreaded] [output]
< _BUILD [build-id]
- build-id: numeric id, created by server
- conf-options: tools/configure options
- revision: the subversion revision number to build
- zip: zip=send zip, nozip=don't send zip
- multithreaded: mt=build is multithreaded (-j), st=build is single-thread
- output: the main output file name this builds create
Several BUILD commands can be sent without waiting for completion. (Client queuing)
>CANCEL [build-id] [revision]
> PING [seqnum]
< _PING [seqnum]
> UPDATE [revision]
Update client script to [revision] and reload.
> HELLO [version] [archlist] [username] [clientname] [cpu] [32/64bit] [os] [bogomips]
< _HELLO [status]
- version: client script version
- archlist: sh,arm,m68k,mipsel,linuxsim,winsim,manual,rbutil
- username: owner of machine/client
- clientname: user-unique name of this running instance
- cpu: output of uname -m
- 32/64: 32 or 64
- os: output of uname -o
- bogomips: how many bogomips the host boasts
- status: ok=ok, baduser=unknown user
> COMPLETED [build-id]
< _COMPLETED [build-id]
Build completed, log and optional zip uploaded.
- Build list is time sorted, longest build first.
- Client list is bogomips sorted, highest first.
- Pop the list, one build per client.
- Loop the client list until all builds are assigned.
- When a client completes all its' builds, give it the first (longest) unfinished build.
- When a build is finished, cancel other clients building it.
- compile times: wallclock time, cpu time, iowait time?
- upload time
- sysinfo: cpu, disk, 64-bit (uname?)
Copyright © by the contributing authors.