On Fri, Jan 17, 2014 at 11:07 AM, John Marino <[email protected]>wrote:
> On 1/17/2014 20:04, Justin Sherrill wrote: > > On Fri, Jan 17, 2014 at 1:45 PM, Brad Fitzpatrick <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > But the Go 1.2 you have already in ports might be sufficient to > > build the builder worker and start the process. Even the plan9 and > > solaris ports started with months of red failure on our dashboard. > > > > > > The best long-term solution is to have a DragonFly system doing > > bleeding-edge Go builds in a loop, correct? Even if it builds in > > (d)ports, that won't catch possible problems until the port itself is > > updated, and I'm assuming the purpose of this is to serve as a sort of > > tinderbox/warning system. > > > > If I can scare up a separate machine to do it, I'd be happy to build it. > > I've been meaning to do something with Go, but like any project, > > without a clear work target it's been hard to get started. > > Justin, > Rather than look for a separate machine, I suggest we add these to > pkgbox64 and pkgbox32 official servers. Then you can tend them there. > > I doubt it's a loop though, it is probably triggered. Maybe even as > often as every new commit. Yes, every commit. The builder program monitors the build master for work. When the master sees new commits, it notifies each worker to do a new build and report the results/output. The build worker (that you will run) will just run all.bash.
