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

Comments

Projects
None yet
4 participants
@jessfraz
Copy link
Contributor

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 label Aug 1, 2017

@bradfitz

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 1, 2017

@jessfraz

This comment has been minimized.

Copy link
Contributor Author

commented Aug 1, 2017

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

@bradfitz

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 1, 2017

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

@cybrcodr

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member

commented Jul 31, 2018

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.

@bradfitz bradfitz closed this Jul 31, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.