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
Assignees
Milestone

Comments

@jessfraz
Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

@bradfitz 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

This comment has been minimized.

Copy link
Contributor Author

@jessfraz jessfraz commented Aug 1, 2017

@jessfraz

This comment has been minimized.

Copy link
Contributor Author

@jessfraz jessfraz commented Aug 1, 2017

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

@bradfitz

This comment has been minimized.

Copy link
Contributor

@bradfitz 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

This comment has been minimized.

Copy link
Contributor Author

@jessfraz jessfraz commented Aug 1, 2017

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

@cybrcodr

This comment has been minimized.

Copy link
Contributor

@cybrcodr 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

This comment has been minimized.

Copy link
Contributor

@bradfitz 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

This comment has been minimized.

Copy link
Contributor

@bradfitz bradfitz 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
@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.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.