-
Notifications
You must be signed in to change notification settings - Fork 18k
x/build/cmd/builder: delete #21191
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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. |
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
Is the |
@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: |
… support Step 1 of migrating cmd/builder users to cmd/buildlet users: delete unused code to make sense of what actually remains. Updates golang/go#21191 Change-Id: I74d52d49ea0f3ff347ff188dcc0f2c491afca2ff Reviewed-on: https://go-review.googlesource.com/51830 Reviewed-by: Andrew Bonventre <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]> Reviewed-by: Herbie Ong <[email protected]>
Change https://golang.org/cl/52632 mentions this issue: |
Updates golang/go#21191 Change-Id: I83319a4994959c31be2d41ec4622aac5f3ee4eca Reviewed-on: https://go-review.googlesource.com/52632 Reviewed-by: Herbie Ong <[email protected]> Reviewed-by: Andrew Bonventre <[email protected]>
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
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 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 |
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: |
Updates golang/go#21191 Change-Id: I636204e9e4cbe77e34b2bbad65312fb6f2ace2dc Reviewed-on: https://go-review.googlesource.com/53490 Reviewed-by: Brad Fitzpatrick <[email protected]>
Change https://golang.org/cl/53491 mentions this issue: |
Updates golang/go#21191 Change-Id: I09854a99c17dec204ee3a1f7c197bb7b69895979 Reviewed-on: https://go-review.googlesource.com/53491 Reviewed-by: Yuval Pavel Zholkover <[email protected]> Reviewed-by: Brad Fitzpatrick <[email protected]>
Okay, the three remaining are: plan9-arm (@0intro) @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: |
Change https://golang.org/cl/53493 mentions this issue: |
No point snapshotting for non-sharded builders. And snapshotting is too slow and hits the timeout on freebsd-arm. Updates golang/go#21191 Change-Id: I225aa6af493b92aa45589491c69853e13d513dd1 Reviewed-on: https://go-review.googlesource.com/53493 Reviewed-by: Yuval Pavel Zholkover <[email protected]> Reviewed-by: Brad Fitzpatrick <[email protected]>
Change https://golang.org/cl/53473 mentions this issue: |
The plan9-arm-0intro buildlet is now running. |
On Plan 9, the home environment variable contains the user's home directory. Updates golang/go#21191 Change-Id: Ia421aebe5b3cfec6a2baa1bb7972183c8be19b97 Reviewed-on: https://go-review.googlesource.com/53473 Reviewed-by: Brad Fitzpatrick <[email protected]>
Currently the buildlet ignores any GOROOT_BOOTSTRAP defined on the host, assuming it'll always come from the coordinator. Relax that a bit to make it easier to migrate people to buildlet from the older builder. This doesn't change behavior for any existing builder. Updates golang/go#21191 Change-Id: I3c3ef77b073d7cecf41855e6d060773b8558935b Reviewed-on: https://go-review.googlesource.com/53492 Reviewed-by: Yuval Pavel Zholkover <[email protected]> Reviewed-by: Brad Fitzpatrick <[email protected]>
Change https://golang.org/cl/53417 mentions this issue: |
The plan9-amd64-0intro buildlet is now running. |
Updates golang/go#21191 Change-Id: I577dad51d490d7e281ccde9fa7d82bb1bee95bd9 Reviewed-on: https://go-review.googlesource.com/53417 Reviewed-by: David du Colombier <[email protected]>
And I've now restarted the coordinator at golang/build@2446fb3 |
Change https://golang.org/cl/53475 mentions this issue: |
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 |
Yes, the plan9-amd64 and plan9-arm builders are not using |
Thanks @0intro. @davecheney Can you please update me on status of the
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: |
I followed up by removing the old-style builder section from the DashboardBuilders wiki page. |
It turns out the |
It looks like we missed the It was mentioned in the now-deleted "Old-style builders" section of golang.org/wiki/DashboardBuilders. @4a6f656c, are you interested in migrating the |
We have very few users of the old-style builder left:
https://github.com/golang/go/wiki/DashboardBuilders#old-style-builders
Of the ones I see running, to migrate we have:
nacl-arm-cheney (@davecheney)no longer runningIf we can migrate those few users to
cmd/buildlet
instead we can then deletex/build/cmd/builder
.The text was updated successfully, but these errors were encountered: