open-match-base-build shouldn't download all dependencies every time.

[Laremere]

Dockerfile.base-build first copies the local code, then it downloads all of the dependencies. On a normal build, this takes a large portion of the time. Right now github is having some issues (slow, timeouts) with fetching repositories, so building isn't possible.

I think we can get away with less often build image base (only changed when we update versions, or add/remove dependencies). This would significantly increase build speed and iteration time.

While we're at it, each Dockerfile independently starts up, builds the single component, starts a new image, and then copies from the build image to the final image. With Go's fantastic build speed, it's likely that for building >=2 images at once (common because the build doesn't auto-detect what deps change) it would be faster to have one image build everything, then just copy from that image directly into the final images.

So, go from:

Dockerfile.base-build:

• From go image
• Copy repo into image
• download deps for project

Component Dockerfiles:

• From base-build
• Build component
• From gcr.io/distroless/static
• Copy component from builder

To:
Deps Dockerfile:

• From go image
• Download all dependencies

Base build Dockerfile:

• From deps dockerfile
• Build all components

Component Dockerfile:

• From gcr.io/distroless/static
• Copy component from build dockerfile

[jeremyje]

See #111 for context.

[sawagh]

Will we target this to v0.6?

[Laremere]

I want to work on it directly after my current v0.6 work, but the way timelines are looking, it's very unlikely. Moved to v0.7.

[Laremere]

This was improved by #664

Pushing back further improvements.

[Laremere]

This has been further improved by go 1.13, which now has a dedicated goproxy. Now a github outage shouldn't take the build down. Building some sort of local go proxy might be an improvement, but that's pretty far outside of the benefits at this point I think. (given how well the build caching seems to be working.)

Going to mark as closed, as there aren't any work items left here where a Open Match specific contribution would dramatically improve things.