Skip to content
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

x/build: use GCP container builder triggers for images? #21249

Closed
jessfraz opened this issue Aug 1, 2017 · 8 comments
Closed

x/build: use GCP container builder triggers for images? #21249

jessfraz opened this issue Aug 1, 2017 · 8 comments
Labels
Builders x/build issues (builders, bots, dashboards) FrozenDueToAge
Milestone

Comments

@jessfraz
Copy link
Contributor

jessfraz commented Aug 1, 2017

Work on converting docker images to GCP container builder and nested builds so we don't have to push and update them all the time.

cc @adams-sarah @cybrcodr @bradfitz

@jessfraz jessfraz self-assigned this Aug 1, 2017
@gopherbot gopherbot added this to the Unreleased milestone Aug 1, 2017
@gopherbot gopherbot added the Builders x/build issues (builders, bots, dashboards) label Aug 1, 2017
@bradfitz
Copy link
Contributor

bradfitz commented Aug 1, 2017

I'm a little apprehensive here.

You say "Switch to X" without a reason, so I'm guessing the reason is that your pushes are slow?

My development VM is already on GCP, so my pushes to gcr.io are super fast already.

I'm concerned that this will only slow down my normal hack+push dev cycle, rather than speed it up, though I imagine this would speed up development if my primary dev machine was my laptop pushing to gcr.io from an airplane.

I believe all of our Dockerfiles are designed to make iterative development pretty painless, caching things at the last step to make the final compile quick, e.g.

https://github.com/golang/build/blob/da1460b7c9c9b65383d1336593ed9ad346f6a1c5/cmd/coordinator/Dockerfile.0#L105

So if we switch to GCP container builder, I want to understand why we're doing it and what we gain, and what sort of latency guarantees they have.

Or I want to preserve the ability to do it the current way, which I find to be interactively useful. I don't want a big slow machine between writing code and prod/staging.

@jessfraz
Copy link
Contributor Author

jessfraz commented Aug 1, 2017 via email

@jessfraz
Copy link
Contributor Author

jessfraz commented Aug 1, 2017

oh ya this was assuming we could have both manual and that

@bradfitz
Copy link
Contributor

bradfitz commented Aug 1, 2017

A computer does it for us already. We type make push-prod. It's not like we're assembling a tarball in a hex editor by hand. :-)

If you just want to use new toys, that's fine, as long as it's optional to start with.

@jessfraz
Copy link
Contributor Author

jessfraz commented Aug 1, 2017

lol well I'm sticking it last on my list haha

@cybrcodr
Copy link
Contributor

cybrcodr commented Aug 1, 2017

Just my thoughts. GCP container builder may be nice to have, but it does come at a cost, so it should only be optional or can be done for "official" builds if we do need such.

I think what may be nice to improve on is switching to multi-stage Dockerfile for the builds, I think that may simplify the Makefile definitions.

@bradfitz
Copy link
Contributor

bradfitz commented Aug 3, 2017

multi-stage Docker would be nice. If we do that, though, make sure that for anybody running too-old Docker versions, we fail nicely with a useful error message.

@bradfitz
Copy link
Contributor

I'm going to close this. We now use multi-stage Dockerfiles and the Makefiles are all super simplified. Things are much cleaner than when this bug was filed.

Even though we still don't use container builder, I'm not sure there's a big advantage.

@golang golang locked and limited conversation to collaborators Jul 31, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Builders x/build issues (builders, bots, dashboards) FrozenDueToAge
Projects
None yet
Development

No branches or pull requests

4 participants