Consider copying host build artifact into docker build

[arkodg]

Continuing the thread from here, another way to package the docker image is to build the go binary on the host and add it into the image using the ADD step. It would look like

Makefile

build: 
          go build -o ./bin  ......

docker-build: build
          docker build -f Dockerfile .

Dockerfile

FROM ....
ADD bin/envoy-gateway .
....

Pros:

• the build is based on the go tooling on the dev/CI's host and so uses any environment set on the host such as GO_PROXY adding more flexibility .
• faster to build the binary in the host than as a intermediate container / docker build step

Cons:

• the above flexibility might come at a cost of inconsistency where a user's go tooling is on a different version than the CI's, creating inconsistent images
• a user on a different OS such as darwin might have to pass different args when building make build to run the go binary locally vs when trying to build a linux based Docker image

[lizan]

• a user on a different OS such as darwin might have to pass different args when building make build to run the go binary locally vs when trying to build a linux based Docker image

Have a build target that sets GOOS correctly then you won't have this issue, like

build-linux-amd64: 
          GOOS=linux GOARCH=amd64 go build -o ./linux/amd64/bin/  ......

build-linux-arm64: 
          GOOS=linux GOARCH=amd64 go build -o ./linux/arm64/bin/  ......

docker-build: build-linux-amd64 build-linux-arm64
          docker build -f Dockerfile .

Then just use ADD ./$TARGETPLATFORM/bin/envoy-gateway /usr/local/bin so you have multiarch image built.

Alternatively we can just use ko as suggested in #89, which essentially does the same stuff.

[arkodg]

thanks @lizan , ive incorporated #93 (comment) into 25373a9
still introduces the issue of a dev image being different from a CI image due to different go versions used, we can revert this change if its an issue later