x/build: run linux-arm-arm5spacemonkey make.bash cross-compiled on fast machines

[bradfitz]

Running make.bash on the ARM5 spacemonkey hardware takes 27 minutes.

We could cross-compile it from Kubernetes like we do for the linux-arm Scaleway trybot builders.

It looks like it's pretty much already set up in coordinator.go,

type crossCompileConfig struct { 
        Buildlet    string 
        CCForTarget string 
        GOARM       string 
} 
 
var crossCompileConfigs = map[string]*crossCompileConfig{ 
        "linux-arm": { 
                Buildlet:    "host-linux-armhf-cross", 
                CCForTarget: "arm-linux-gnueabihf-gcc", 
                GOARM:       "7", 
        }, 
        "linux-arm-arm5spacemonkey": { 
                Buildlet:    "host-linux-armel-cross", 
                CCForTarget: "arm-linux-gnueabi-gcc", 
                GOARM:       "5", 
        }, 
} 
 
func (st *buildStatus) crossCompileMakeAndSnapshot(config *crossCompileConfig) (err error) { 

But this part means it's not being run for non-trybots:

func (st *buildStatus) getCrossCompileConfig() *crossCompileConfig {
        if kubeErr != nil {
                return nil
        }
        if inStaging || st.isTry() {
                return crossCompileConfigs[st.name]
        }
        return nil
}       

/cc @zeebo

[zeebo]

Should we be running for non-trybots? What kind of logic do we want for this?

Let's have it configurable per each cross compiler config and add a OnlyForTry boolean to the config.

[bradfitz]

arm5 is way too slow to ever be a trybot. We're only going to be running post-submit builds for this builder type.

[zeebo]

Ok. I'll just remove that condition then and always return a config if it's available and there's no kubernetes error.

[bradfitz]

Oh, sorry, I misread your comment. We don't want to waste resources cross-compiling for linux-arm for post-submit builds, so:

Let's have it configurable per each cross compiler config and add a OnlyForTry boolean to the config.

Yes, that sounds good. Add that bool.

[gopherbot]

CL https://golang.org/cl/41755 mentions this issue.