Support cloudbuild.yaml

[ahmetb]

It seems like we want to support cloudbuild.yaml in addition to Dockerfiles, and there's a plan to support buildpacks via app.json (#3).

@jamesward What's the primary reason we want to have cloudbuild.yaml? Does it do something potentially we can’t do via docker build with multi-stage Dockerfiles?

I suppose it enables tools where you don't want to use docker and still end up with a docker image (ko, pack etc.), but should we treat this as a priority –especially given the adoption levels of cloudbuild.yaml vs Dockerfiles?

[jamesward]

Good question. I have some repos that use cloudbuild.yaml but I think you are right that those could easily be converted to buildpacks or Dockerfile. And since we can actually do great caching on Cloud Shell, maybe we punt on this for now.

[ahmetb]

Agreed. Based on my experience, the pack stuff isn't in a mature shape yet either (#3), so we can put alternative "builders" on hold for now.

[jamesward]

As #85 points out, one use case for this is builds that use Jib. It doesn't make sense with those to use docker or buildpacks so having a cloudbuild.yaml that specifies the build steps is great.

[jamesward]

As far as implementation... Right now we check for a Dockerfile and if it exists we run docker, otherwise we try the buildpacks. We should first check for a cloudbuild.yaml since a repo can contain both a Dockerfile and a cloudbuild.yaml in which case we should do the Cloud Build.

Like other commands we should tell the user the gcloud command we are running.