add support for building multi-CPU architecture images

[paulfantom]

What this PR does / why we need it:

• finalizing support for creating multi-arch images (Makefile already had some targets to build images for multiple architectures)
• adding support for creating a container manifest joining images into one
• fixing propagation of ARCH variable in kube-state-metrics target
• removed the containerized build process as there is no benefit of it when using go modules.

Tested by running:

make release-images REGISTRY=quay.io/paulfantom TAG=$(git rev-parse --short HEAD)

Output can be seen in https://quay.io/repository/paulfantom/kube-state-metrics?tab=tags

Images validated on ARMv7 and AMD64 systems.

NOTE: This changes how images are published to quay.io. After merging, publishing images is done with make release-images. Added info about it in RELEASE.md

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #1037

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: paulfantom
To complete the pull request process, please assign tariq1890
You can assign the PR to them by writing /assign @tariq1890 in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[brancz]

There is some work on publishing the images to k8s.gcr.io automatically, at that point we will probably no longer support the quay repo. I'm not sure how much work we should put into it. I'm fine with this, but be aware that it might disappear soon, and I don't know if the auto publishing workflow will support multi-arch.

[lilic]

There is some work on publishing the images to k8s.gcr.io automatically, at that point we will probably no longer support the quay repo

Yes we discussed with Pawel :)

I'm fine with this, but be aware that it might disappear soon, and I don't know if the auto publishing workflow will support multi-arch.

Not true, we will still publish the coreos images, no?

[paulfantom]

/hold

Apparently docker on travis has permissions problems when trying to create manifests.

Apparently this is fixed but not really: docker/for-linux#396

[paulfantom]

/unhold

moved to use manifest-tool tool instead of experimental docker feature to solve travis issue with docker permissions. Also simplifies Makefile a bit.

[tariq1890]

Let's move the manifest-tool version to a variable

[tariq1890]

Let's also have a bin existence check, so that we don't run this every time. Something like this:

HAS_GOLANGCI := $(shell which golangci-lint) which is used in the lint make target

[paulfantom]

Simple checking for binary existence is a contrast to requiring a version of a binary. Consider having a pre-existing system-wide binary in version A, but specifying version B in Makefile. In such scenario you would need to add another check to validate globally installed binary version against version requested in Makefile. It is a question of code simplicity vs first execution speed.

[tariq1890]

Why not have clean as a pre-requisite to the sub-container-% target?

[paulfantom]

That was the first thing I did, but it didn't work 🤷

[tariq1890]

Why not have clean as a pre-requisite to the sub-push-% target?

[tariq1890]

Thanks for the PR @paulfantom :). Provided some review comments

[mrueg]

@tariq1890 @paulfantom since I'm using kube-state-metrics on arm64, I would love to see this change in as it will simplifying deployment a lot. Anything I can help out with here to move it forward?

[paulfantom]

@mrueg AFAIK right now kube-state-metrics is moving container builds to gcr (#1155). After that move is done I don't this PR is necessary anymore (definitely not in this form).

Since right now I don't have time or desire to investigate this issue again, I am closing it.