Google announces Cloud Build, its new continuous integration platform

It's the same product -- it was just renamed.

I would make build triggers that are based on specific Dockerfiles changing in the repo. Many CI systems can watch a specific file being changed as the task trigger.

So if container A is a dependency for container B, then make container B's task trigger be whenever the Dockerfile for container A changes.

Several hour builds? I have to ask what kind of app this is for, because I haven’t ever had a build take more than 2 minutes. I’ve been using docker heavily in CI/dev for about 2ish years and the past couple months been getting some production stuff going.

My first thought since you say you’re having issues with build caching, you might want to look into multi-stage builds[1], if you haven’t already. I haven’t gotten any “heavy” use from these since I mostly do web stuff in non compiled languages, so I can’t benefit from this feature as much as a compiled language than can just copy binaries around. But, it has been useful for like compiling JS, since it’s done in a separate stage, I a) don’t ever have to contaminate my final image with a node_modules at any point and b) can rebuild the image and used the cached stage if there are no changes in the front end, and that’s usually the longest parts of my builds anyway.

However, if you’re in a compiled language (which from the sounds of it, I have a feeling you might be — long builds and multiple dependent components that have to be rebuilt), you can compile some core component in the first stage (A), then have multiple stages (B, C) that depend on that component’s compiled files, and then maybe a final stage (D) that depends on B & C. So then, if you make changes to just C, you’ll only have to rebuild the C & D stages, while the other two are cached. Each stage itself is just an intermediary image, so you can use them as you would the final, and you can even tell Docker to just build up to stage B, if you only need that image.

[1] https://docs.docker.com/develop/develop-images/multistage-bu...

Seems like a build pipeline may be the way to go. Check out Concourse CI or Jenkins Pipelines.

Those allow to define multi-stage builds with custom triggers, which should allow you to trigger rebuilding dependent images.

I take it as a sign that the value bar keeps getting raised for small players to exist. CI is becoming so commodity that it doesn't really matter if you get it from Google or Codeship. If a slow-moving corporate machine can replicate what you do...maybe you need to move faster.

> does anyone else get a little upset when GCP, AWS, and Azure are able to buy their way into a market

There's benefits to smaller, hungrier teams building things, but unless they have paying customers on day one they're also buying their way into the market one way or another...

I understand this, my company is currently dealing with a similar situation. We have a small vendor that hosts things, but I am pushing to drop them for Azure because it offers so many more features and tools that the vendor just can't match. It's kind of an acquisition thing, we acquired a company that deals with this vendor, we were already using Azure. It's much harder to go off the cloud than to go on it, imo. You just lose so many great features when you move off of it. It's sad, but at the same time it's becoming impossible for smaller people to compete in a cloud world. I don't think that's going to change. My biggest fear is that once all the small players are killed off Google, Microsoft and AWS will agree in some back room to not compete on price to protect their margins. I have a feeling that something like that is merely a decade away, if not less.

this is the reason companies build platforms. If you own the platform, you get a big advantage over third-parties building tools on your platforms. they aren't buying their way into the market with money, they're buying their way into the market with years and years of work building the platform. I don't think it's anything to get upset about.

Also, the big cloud platforms aren't shy about acquiring smaller players, and that's an exit that a lot of the people building tools for cloud platforms are looking for. I think it's safe to say that without GCP, AWS, and Azure there'd be a lot fewer companies building CI tools.

As much as big players move into green pastures - so do open source projects. It's more about low-hanging fruit than anything else.

Yes. I have no skin in this game personally but I feel bad when Google or one of the other behemoth's of tech decide to offer a service that small players are already thriving in. Google can compete with a scale of development that can easily drive the small guys out of business. What's worse is that they then get bored with the product at some point, or a pointy haired boss looks sadly at a revenue chart and the thing suddenly disappears with no recourse and the small players are gone.

I know next to nothing about this, but there seem to be instructions on how to deploy to App Engine. See the App Engine tab under "Deploying artifacts" [1]. Is there more that's needed?

[1] https://cloud.google.com/cloud-build/docs/configuring-builds...

How do you figure this? There's certainly a `gcloud` step available, you can integrate with any GCP services here.

Why? I'd have thought CI is a place where per-second billing would be an advantage? A CI job is likely to take somewhere between 1 and 15 minutes, per second billing could be a significant saving for many users.

Bitbucket Pipelines charges per minute as well: https://bitbucket.org/product/features/pipelines

I've been introducing Jason and Christopher from the Cloud Builder team to Concourse over the past few months. Jason & Co also developed Knative Build which closely tracks the Cloud Builder design.

I am hoping to see Concourse come in through the Pipelines proposal on Knative, but it will be necessary to digest a Concourse-on-Kubernetes epic first.

(Please come and sing the Concourse-is-amazing hymn with me on Knative, we both know it's for the good)

Disclosure: for those who don't know, I work for Pivotal and I'm a bit of a Concourse fan.

It doesn't appear to be a rebranding, but an upgrade or a rewrite, since the site mentions the first two points (that I checked):

https://cloud.google.com/cloud-build/

"Set up triggers to automatically build, test, or deploy source code when you push changes to GitHub, Cloud Source Repositories, or a Bitbucket repository."

https://cloud.google.com/cloud-build/docs/configure-third-pa...

I looked at Container Builder before and, like you, was not impressed, but this is something else.

The demo I just saw certainly seemed to have all of those things (except possibly PR status updates and outside integrations). I don't think it's a rebranding but an update.

We've been using https://drone.io/ for some time, which is very, very similar, but if we weren't I'd give it some serious consideration.

> Ability to send messages to slack on successful / failed builds

That should be easy enough, request a new cloud builder Slack. Currently this is possible though using the curl cloud builder and constructing a custom curl request to the Slack API.

> No story on how to store secrets

Agree, need a way to mark variables as sensitive/secure. Don't show them in the build history in plain text and make the input field of password type. Encrypt somehow when stored as well.

> Conditional build steps AT ALL

Agree, this is a biggest missing piece.

Hi, member of the Google Cloud Build team here. Appreciate all the feedback on the launch! Yes it's both a rebrand as well as an update.

When we first launched Container Builder a year ago we always had a plan to support more CI use cases. With the launch today we've added a few new features such as:

- Built-in support for pushing non-container artifacts to Google Cloud Storage

- Filepath triggers for invoking builds only on changes to certain subdirectories or files

- Updates to the Cloud Console UI and of the Cloud SDK (from `gcloud container builds...` to `gcloud builds...`)

We have more updates in alpha now including built-in support for GitHub pull requests, status/Checks API support, and programmatic triggers, which we agree is one of the biggest missing pieces for many people. That GitHub app is the first step with more granular control over PR triggers coming soon.

We try not to comment on roadmap items but looking ahead a little, this rebrand is also an indication of the product's focus on broader CI/CD use cases, which many of our users are already using Cloud Build for, and an evolution towards bringing DevOps and Continuous Integration best practices to Google Cloud users. Feature requests like built-in conditional steps and notifications are on our radar and we always appreciate hearing from users what they'd like to see us prioritize.

Release notes are published here for anyone interested in updates on new features. https://cloud.google.com/cloud-build/release-notes

There's a public Slack channel as well where GCB users and the Cloud Build team discuss features an different use cases. Happy to see anyone on there. https://googlecloud-community.slack.com/messages/C4KCRJL4D/c...

We appreciate all the positive feedback on the thread as well. We're excited about what's ahead for Cloud Build and that it's helping people be more productive!

It did for us, its really easy to create a trigger on a Github branch, run tests, build the executable, and deploy (in out case to k8s). Super quick builds too.

Not if you want to build on Mac or Windows.

Maybe they'll just rename it in 18 months. That would be an improvement and someone can still get a promotion. Now, they just to think up a new name for Reader.

My thoughts exactly. Too much risk to commit to Google platform. I will wait for Mozilla cloud instead.

You know this comment has become a cliche?