skj

38 ms·

391.
by skj 10y ago
We don't currently have a supported way to inject Docker Hub credentials into your build, but it's a feature we have our eye on.
392.
by skj 10y ago
GCCB does inside-VM parallelism with build steps, but the service itself does not support fan-out to multiple machines. I think of GCCB as a building block on which a fan-out product can be built on. In fact, here is some vaporware: https:
393.
by skj 10y ago
We recognize the demand, and we're open to trying to get things working, but currently there is no support.
394.
by skj 10y ago
Absolutely. Under the covers, GCCB is an arbitrary execution engine - we run a series of containers for you. On top of that, we provide a lot of nice dressing to make it convenient and easy to build containers. https://cloud.goog
395.
by skj 10y ago
If you send me an email (skelterjohn at google dot com) I'd love to help you get things working with that repo and GCCB.
396.
by skj 10y ago
You may be interested in trying GCCB with the bazel build step: https://github.com/GoogleCloudPlatform/cloud-builders/tree/m... In a GCCB build, we volume-mount in the VM host's docker daemon socket, so
397.
by skj 10y ago
We've tried to satisfy the 90% case with the UI and "easy" options, especially those that transfer well from other push-to-build products. To keep the UI simple and understandable for everyone, we decided to drop some options
398.
by skj 10y ago
We currently don't have direct support for secrets other than your service account's access tokens. We hope to support more arbitrary secrets in the future. As you said, you can bake things into a base image (ew) or use your crede
399.
by skj 10y ago
My general advice is to do integration testing after push. You say that you value the testing harness having the same set of dependencies as your deployable artifact. With GCCB, you are not limited to one image with your build - it can be a
400.
by skj 10y ago
Couldn't you FROM and then update? I'm not a ruby expert but I'd hope that it could be incremental.
401.
by skj 10y ago
"speed": We start most builds in under a second, but we don't currently offer an SLA. "parallelism": You can indicate any kind of concurrency topology you like with the "wait_for" field on a step: see htt
402.
by skj 10y ago
One approach to this problem that I like is storing these dependencies in an intermediate image. Then, you can do an incremental build by referencing (rather than rebuilding) this intermediate image, and pay only the cost of downloading the
403.
by skj 10y ago
The difference between including the JDK vs only the JRE in your deployable image can mean hundreds of megabytes saved. If you're trying to roll out this image to hundreds or thousands of nodes, this can save a lot of resources. Additi
404.
by skj 10y ago
We don't currently cache anything from one build to the next. We are open to optimizations here, in the future.
405.
by skj 10y ago
It's been around for a while, just under the radar. The service has backed App Engine Flexible environments for almost a year, it's been GA for months, but this is our first public spotlight.
406.
by skj 10y ago
I really like rocket, and technically you can build and push rkt images right now, though it would require a lot of rocket knowhow. Briefly, you can run any container image as a build step with this service, including one that builds rocket
407.
by skj 10y ago
re: link the container with external containers, that's a bit tricky and generally I think that's a space you should use a "dev" environment for. We like to be the connection between source and registry, with your dev
408.
by skj 10y ago
In addition to the "typical" kinds of builds you'll get with existing services (ie run 'docker build' and 'docker push' for me), we offer a flexible and powerful configuration language: https://
409.
by skj 10y ago
We agree! We maintain the official plugins (which we call "build steps" or "builders") here: https://github.com/googlecloudplatform/cloud-builders Support is limited, more or less, to what I am real
410.
by skj 10y ago
Hi all, I'm on the eng team for this service. Happy to answer any questions, and I'll do my best to monitor the threads.
411.
Style guide for professional, clear writing(cs.rutgers.edu)
2 points by skj 10y ago|0 comments
412.
by skj 10y ago
Your questions are making presuppositions that I'm not sure are true.
413.
by skj 10y ago
Next 2.5 at most.
414.
by skj 10y ago
Only because you did it twice... "rogue".
415.
by skj 10y ago
The fact that some missions are more consequential than others doesn't dilute the meaning of "mission critical" for whatever you're talking about. It's critical to that mission, not the forward progress of humanit
416.
by skj 10y ago
That's not part of the drive/docs suite.
417.
by skj 10y ago
Google doesn't need a better algorithm; search is simply a stronger buy-signal than conversation.
418.
by skj 10y ago
Well, it's the definition. I also believe that OS X and iOS have diverged somewhat in the kernal/framework space.
419.
by skj 10y ago
I think a single platform for all our devices: mobile, tablet, desktop, etc, is a mistake. The word platform means more than just the OS and includes the entire L&F/experience with the UI. I think a single OS for them all is fine.
420.
by skj 10y ago
You listed windowing/UI concerns. And, while they may commonly come bundled with the OS, they're not the same thing.

More ›