This looks great. One question: We're currently using Drone (the open-source self-hosted version), which allows us to define a number of parallel sidecar containers ("compose") as part of the build pipeline.

We start things like PostgreSQL and Elasticsearch like this because a lot of tests need to exercise the actual data storage instead of (or in addition to) mocking/emulating them. The container builder thus doubles as a CI server, since every build needs to be tested anyway, and tests need to go through very much the same steps (install dependencies, build source and so on). Tests benefit from being run on the exact same filesystem that the final code runs on, guaranteeing that dependencies are identical.

From what I can tell, such a setup is not supported by GCCB?

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 any number of them.

So, something like

  1. build the deployable as gcr.io/project/service:${REVISION_ID}
  2. build the testing harness as gcr.io/project/testing:${REVISION_ID}
  3. build the db container as gcr.io/project/db:${REVISION_ID}

Then, you can spin up a test environment using the ${REVISION_ID} tags, and do your integration testing there with the same nice guarantees.

That all said, it's certainly possible to do fancier things within the build itself. Using the gcr.io/cloud-builders/docker build step, you can run any docker command. We haven't seen the need to directly support a docker-compose build step, but making it would be easy (different entrypoint on the docker build step) and it would automatically connect to the worker host's daemon.

You can also run several of these docker build steps in parallel, or run one that does 'docker run --name=foo -d ...' and have the others run with '--link foo:foo', etc.

We try not to limit the sorts of things you can do, and provide bonus features like the docker daemon's socket, service account credentials etc.

You don't even need to build a container image, if you don't want to. Just provide some container images and we'll run them for you, pipe the logs back to you, and let you know how it went.

Hm, that's a bit much. In particular as various apps have a different setup (we're a microservice shop and have tons of them, although a minority needs external dependencies for tests like these). Splitting it up like that also generates a dependency, which adds a burden on an already complicated workflow. Drone just solves that so much better by keeping everything in a single, simple build file.

I agree, the semantics required to define the build in GCCB seems really limiting, going to stick to Drone until this matures a bit. The plugin ability of Drone really outshines the current as well.

Very glad that you are offering this service. A key feature needed is speed, i.e. minimal time from check-in through build/unit & integration tests/image/deploy. Questions: - What delay can we expect from check-in to start of build (seconds, minutes?) - What kind of compute power/memory is available for the build? if I run on fast CPU vs slow CPU that makes obviously a difference. What does this service run on? - Is there a way to allocate more vertical resources (more CPU/memory)? - Can parts of the pipeline be parallelized, e.g. run certain tests in parallel (using more than one core/machine)?

"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 https://cloud.google.com/container-builder/docs/api/build-st...

"different machines / resources": Currently it's n1-standard-1 GCE VMs. It's possible that in the future we may become more flexible.

Thanks!

Is there any caching involved?

In other words, what happens if I build the same source tree twice or if one line changes between one run and the next?

We don't currently cache anything from one build to the next. We are open to optimizations here, in the future.

Our Python dependencies include gensim and numpy which puts the build > 10min. Without layer caching, what can I do to get the build time down?

In my mind, at least for custom builds, the most widely-applicable optimization would be providing the build environment with a FUSE-mounted build-cache GCS bucket. Such a mount could then be used in ways similar to the way Heroku's buildpacks use their build artifact cache directory.

Could this be used as a more general CI service without deploying docker containers as the end result?

For example to build a C++ project, run tests, and publish resulting artefacts (binaries, tarballs) in some release repository?

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.google.com/container-builder/docs/api/build-st... and https://cloud.google.com/container-builder/docs/api/custom-b... are documentation on how to use and create your own custom build steps.

Additionally, your build steps have access to the credentials of the service account used to run your build, so pushing to Cloud Storage, for instance, is straightforward (use the gsutil build step).

You support Github push hook. Any plan to give us CI status? For now, I'll create a CI status with curl... https://developer.github.com/v3/repos/statuses/

We don't have any direct support of GitHub status updates. You can make whatever requests from within the build (presumably at the end), but we don't (yet!) have a supported way to get secrets into the build for access to POST the new status.

GCCB will also publish on Cloud Pub/Sub when the build's status changes (including when it goes to "SUCCESS" or "FAILURE"), and you can tell Cloud Pub/Sub to make POST requests with that data, but the format is not flexible so it might not work out for GitHub status updates.

Thanks. On build failure the last step are not executed I think. So I'll check cloud pub/sub.

BTW, are there any community or (public) support channel out there? You know a HN thread is not a permanent place.

I searched on SO, but no label of google cloud container builder yet. http://stackoverflow.com/search?q=google+cloud+container+bui...

I'm not quite a novice but not a real developer by any means. I'm interested in learning more about containers and using them with my RoR side projects.

Is this new product a good place to start that would be relatively pain free for someone new to containers?

If you're new to containers, I recommend starting by learning all about Dockerfiles. You can build them on your own machine, or with GCCB (using the `gcloud` command-line tool).

Dockerfiles make it challenging to keep your build-time environment separate from the run-time environment. For instance, you need the JDK to build your java app, but only the much smaller JRE to run it. Or maybe you want to use bazel.io for building, and have a completely different base image in mind for your deployment. Or maybe you want to bring in a unit testing harness and not publish the image unless all the tests pass.

Once these issues start to matter, GCCB has a great story. In essence, GCCB runs a series of containers with your source mounted in. So, you can run one step to run unit tests, another to build a binary, and a third to package everything into a container image.

GCCB also will build as many containers as you want in a single execution, so if you have several microservices that are all versioned together, you can build them at the same time and give them a `:${REVISION_ID}` tag - useful for production rollouts.

The pricing page doesn't mention any information about data ingress/egress. Care to clarify please?

The cloudbuild service operates some other services on your behalf, and their relevant charges apply.

This most notably includes Cloud Storage (GCR is backed by Cloud Storage). If you use 'gcloud container builds submit' to kick off a build, Cloud Storage is used to get the source in as well.

How are secrets intended to be managed? E.g.: NPM auth tokens (for private NPM modules), Github tokens (e.g. for private Ruby gems or submodules), Slack webhooks, etc.

I suppose one could bake that stuff into a base image, or store it in a Kubernetes secret that the build service account has access to.

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 credentials to fetch them from somewhere else (I suggest Cloud Storage).

The problem with uploading them somewhere is that you introduce an implicit dependency that must be documented and dealt with as part of the whole devops universe — it's just one more thing on top of a heap of other things.

It's much nicer, and more secure (in terms of locking down just one thing and not having to manage multiple to be able to centralize secrets somewhere. Whereas keeping things like this close the project is of course more convenient for developers.

Drone has tried two different systems, neither of which were ideal, and is working on a third one. I believe the third one also involves encrypted secrets committed to the project repo.

Thank you for the input -- we do recognize the importance of being able to manage secure inputs to your builds and are investigating good solutions for this.

Thanks skj.. any plans of supporting containers other than docker ?

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 containers, and including one that pushes them. But, we're not currently offering any direct support for this ability.

rkt supports running Docker Images[1], Open Container Initiative (OCI) Images[2], and appc images.

So, any container image this system builds will run under rkt.

rkt is explicitly designed as a container engine not as a container build system. And this is because build and execute are largely separate concerns. And it leaves the door open for new build systems as demonstrated here by Google.

[1] https://coreos.com/rkt/docs/latest/running-docker-images.htm...

[2] https://github.com/opencontainers/image-spec/issues/126#issu...

Any support currently or planned for windows container builds?

We recognize the demand, and we're open to trying to get things working, but currently there is no support.

Hi, How does this work with regards to build parallelism? For examples builds that make use of outside parallel services such as ElectricAccelerator or Incredibuild?

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://github.com/skelterjohn/flargo (a 20% project that is mostly just some ideas right now) (I am skelterjohn).

While some of our targets will be Google App Engine Flexible, some will be GAE standard. Can we use it with GAE standard as well?

While we are focused on building Docker containers, you are not required to produce a container in your build. Any other built artifacts will need to be copied to persistent storage in one of your build steps.