-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
Comments
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. 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. |
It's not that it's slow it's more like "why must I do this when a computer
can do it for me"
…On Mon, Jul 31, 2017 at 9:52 PM, Brad Fitzpatrick ***@***.***> wrote:
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/da1460b7c9c9b65383d1336593ed9a
d346f6a1c5/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.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
<#21249 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABYNbPT-MevdvAAIaHVR19DhxRMhQieSks5sToT4gaJpZM4OpHeg>
.
--
Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu <http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3>
|
oh ya this was assuming we could have both manual and that |
A computer does it for us already. We type If you just want to use new toys, that's fine, as long as it's optional to start with. |
lol well I'm sticking it last on my list haha |
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. |
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. |
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. |
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
The text was updated successfully, but these errors were encountered: