/cc @adams-sarah @jessfraz @cybrcodr @andybons

There is also:

plan9-arm (@0intro)

plan9-386-ducolombier is a temporary builder. It will go away once GCE is fixed.

David, can you start migrating at least plan9-arm and plan9-amd64-9front to the new system? I can get you new host keys and send you a CL for the dashboard/builders.go CL if so.

How does one migrate from old-style builder to using the buildlet? Are these the instructions ...

https://github.com/golang/go/wiki/DashboardBuilders#how-to-set-up-a-builder

Is the key (.gobuildkey) used for initial buildlet run only or is it permanent for all future runs?

Step 6. Have golang-dev deploy it. -- does "it" here pertain to dashboard or do we also need to redeploy coordinator and others?

Yes, those are the instructions.

The build key is required whenever the buildlet wants to register itself with the coordinator, which happens once per run, or whenever one of them restarts.

Step 6. Have golang-dev deploy it. -- does "it" here pertain to dashboard or do we also need to redeploy coordinator and others?

Only the coordinator. The dashboard doesn't need updates currently. If #19930 gets fixed, though, then restarting the dashboard would be nice but not required.

@bradfitz how do I

get a builder host type & hash

Is the builder=freebsd-arm query param to the https://build-dot-golang-org.appspot.com/key endpoint supposed to work for with my gmail account?
What should I do with my current hash in .gobuildkey file?

@paulzhol, email me (bradfitz golang) and I'll get you keys.

Actually, I might have a new plan. I think I can just modify the buildlet a bit to work with your existing files & keys unmodified. That'd be easier for everybody.

Great! I'll take the opportunity to upgrade to FreeBSD-11.1 while waiting for the new buildlet.

Change https://golang.org/cl/51830 mentions this issue: cmd/builder: delete unused gccgo, old^2 perf dashboard, and mercurial support

Change https://golang.org/cl/52632 mentions this issue: cmd/builder: update docs, delete more dead code

I think I have succeeded in switching dragonflybsd to the new builder. Note that @fupjack has not maintained the builder for some time now, so please update your list.

@tdfbsd, I see "dragonfly-amd64" connected now, thanks. But it won't get any work without some config on our side.

Are you running it in a loop so it'll re-run on process exit? (ideally in a container with a fresh filesystem)

Also, are you the new owner of that builder? Thanks!

I've been running it for a year now. I can run it in a loop if that's the preferred way. I don't know what "container with a fresh filesystem" means.

@bradfitz can you see freebsd-arm-paulzhol as well? I'm running buildlet with the following parameters:
-coordinator farmer.golang.org -halt=false -reverse-type freebsd-arm-paulzhol

2017/08/05 20:51:04 buildlet starting.
2017/08/05 20:51:04 Not on GCE; not remounting root filesystem.
2017/08/05 20:51:04 Dialing coordinator farmer.golang.org:443 ...
2017/08/05 20:51:05 Doing TLS handshake with coordinator (verifying hostname "farmer.golang.org")...
2017/08/05 20:51:05 Registering reverse mode with coordinator...
2017/08/05 20:51:05 Connected to coordinator; reverse dialing active

Not building anything though.

@tdfbsd, where is your GOROOT_BOOTSTRAP directory? With the new system, that's set on our side. (The new system didn't really consider 1-off builders in its design, but I suppose we could make some changes to make this easier if it becomes tedious.)

And yes, you'll need to run the loop yourself. After each build, the buildlet process will terminate. (Or it will halt the machine by default, unless --halt=false is given.)

By fresh filesystem I mean that ideally each build would run in a hermetic environment so any changes it makes are undone when the process ends and starts anew. Whether that's something like a Docker container or an overflay filesystem or a VM varies by builder. Some of our builders don't do that, and that's okay. For the most part it tries to be well-behaved. The fresh-filesystem-per-build is just paranoia.

@paulzhol, same question about where your GOROOT_BOOTSTRAP is. But I see freebsd-arm-paulzhol connected.

@bradfitz I haven't set it to anything, so it defaults to $HOME/go1.4 I think.
What about other environment variables, the old builder had GOARM=7 CGO_ENABLED=1 GO_TEST_TIMEOUT_SCALE=32. Will they be inherited by the buildlet process?

Actually, I was wrong. The environment of commands executed under the buildlet includes (unless overridden) all of its initial environment.

Change https://golang.org/cl/53490 mentions this issue: dashboard: update dragonfly-amd64 and freebsd-arm to be buildlet-based

Change https://golang.org/cl/53491 mentions this issue: dashboard: set GOROOT_BOOTSTRAP for dragonfly-amd64 and freebsd-arm

Okay, the three remaining are:

plan9-arm (@0intro)
plan9-amd64-9front (@0intro)
nacl-arm-cheney (@davecheney)

@0intro, can you kill the plan9-amd64 builder? That is #19388. And I've mailed you a host key for migrating plan9-arm.

@davecheney, that leaves your nacl-arm builder as the last cmd/builder user to migrate.

Change https://golang.org/cl/53492 mentions this issue: cmd/buildlet: use inherited GOROOT_BOOTSTRAP as fallback

Change https://golang.org/cl/53493 mentions this issue: dashboard: set SkipSnapshot on freebsd-arm and dragonfly-amd64

Change https://golang.org/cl/53473 mentions this issue: cmd/buildlet: fix homedir on Plan 9

The plan9-arm-0intro buildlet is now running.

Change https://golang.org/cl/53417 mentions this issue: dashboard: convert plan9-arm, plan9-amd64-9front, nacl-arm to buildlets

The plan9-amd64-0intro buildlet is now running.

And I've now restarted the coordinator at golang/build@2446fb3

Change https://golang.org/cl/53475 mentions this issue: cmd/buildlet: don't set GOROOT_BOOTSTRAP if already set

Based on #21191 (comment), CL 53417, and #21191 (comment), it sounds like all the 3 remaining old-style builders have been migrated. Is that so? Is anything left to be able to remove cmd/builder and close this issue?

Yes, the plan9-amd64 and plan9-arm builders are not using cmd/builder anymore.

Thanks @0intro.

@davecheney Can you please update me on status of the nacl-arm-cheney builder? Based on CL 53417, it looks like it should be migrated. However, on https://farmer.golang.org/, I see:

host-nacl-arm-davecheney: 0/0 (1 missing)

So it's not connected right now.

ping @davecheney

It’s no longer running , sorry.

Updated the checklist. Looks like we can move forward.

Change https://golang.org/cl/161118 mentions this issue: cmd/builder: delete

I followed up by removing the old-style builder section from the DashboardBuilders wiki page.

It turns out the netbsd-arm-bsiegert builder is still running the old builder command. I was not aware of this issue when I set it up in March 2018.

It looks like we missed the openbsd-arm builder in this issue. /cc @4a6f656c @bradfitz @bcmills

It was mentioned in the now-deleted "Old-style builders" section of golang.org/wiki/DashboardBuilders.

@4a6f656c, are you interested in migrating the openbsd-arm builder to use cmd/buildlet (the general process is described here)?