Do not build the mvn-gcloud builder image during Cloud Build executions

[aslo]

I set up a build trigger that will rebuild and push the gcr.io/java-runtime-test/mvn-gcloud-builder image on every push to master. Now, we don't need to rebuild this image during Cloud Build executions.

fixes #155

[meltsufin]

How are we going to know if this trigger-based build is failing?
I think I prefer to actually building the mvn-gcloud-builder image during every execution as long as it's part of this codebase. Is the concern mostly around the speed of the integration testing?

[aslo]

Code reuse is another big part of this. If we separate this image's build from the runtime release builds, all of the runtimes can use it easily. Right now the openjdk and jetty runtimes contain very similar dockerfiles that are used for the same thing.

[meltsufin]

It sounds like a useful build step. Would it make any sense to host it here alongside other Cloud Build steps?

[aslo]

I'm not sure it would necessarily make sense. This image is somewhat specific to our use case, so I'm not sure how much value customers would get from it. Also, if we were to add it to the cloud-builders repo, we would no longer control it. There's additional overhead there in terms of getting new images released and updated.

[meltsufin]

Maybe we can just use a wget step to download gcloud as part of the build?

[balopat]

The problem I see with the current design is:

• we could use the exact same step in other runtimes, but with the sizable Dockerfile definition that duplication seems problematic
• we build and install python and gcloud on top of maven for every build (this could be okay in the end, if we find build wait times are cheaper than maintenance overhead created by alternative solutions)

Design alternatives:

1. build and host somewhere:

• Hosting it in cloud builders - the problem is not with specificity but rather that those builders seem to be "single-tool" images, while this one is a "multi-tool" image, so it would break that consistency.
• Hosting it ourselves (java-runtimes) - the problem is maintenance overhead and extra jobs to ensure this is always there

2. simplify build step (if we're okay to incur the build time)

• We could simulate a "mixed step" like: "from mvn+gcloud" with a multistage Dockerfile potentially? The small Dockerfile might be okay to duplicate - @aslo do you mind testing out whether a multistage Dockerfile would look simple enough?
• Simple wget might reduce the Dockerfile size too - if we can do it cleanly

[aslo]

do you mind testing out whether a multistage Dockerfile would look simple enough?

Happy to take a look at it, but I'm pretty sure that the multistage dockerfile would need to be virtually identical to the mvn-gcloud dockerfile we have now. I'm not sure how we'd be able to get around duplicating all that.

[aslo]

@meltsufin and I decided to close this to revisit later.