Create and publish linux/amd64 and linux/arm64 builds on release

[mmoscher]

Change log description

This PR creates mutliarch builds of pravega/zookeeper-operator and pravega/zookeeper using docker buildx when a new GitHub release is crafted.

However... the available publish job in the ci.yaml GHA workflow was broken. For example, the job does no code-checkout at all and thus was uncapable of running (finding) the Makefile. Uhrgs.

Question: Is the provided GHA worklfow and your push Makefile-target used at all? IMHO not :/ :(
Because: a) the "ALTREPO" used in the Makefile for pushing image (make push) is pointing to another docker-hub repo where another user is pushing docker-images. For example, in the pravega docker-hub repos a user called pravegaci is pushing images, whereas in the emccorp repos the user is called ecsjenkins. Since the Makefile has only one docker login call, pushing with different users in a CI environment is impossible.
b) Additionally, the emccorp/zookeeper-operator:latest tag was created 3 years ago whereas the latest tag is ~5 months old. An automated push on release to the altrepo would have created the tag "latest" as well.

All-in-all: it seems there is another CI or manual build-process in place, for what reason I'm uncertain if this PR will help at all :(

@anishakj pretty please clarify how you are publishing your docker-images. Thanks :)

Purpose of the change

• Fixes Support ARM64 #320
• Fixes Any plan to support aarch64? #500
• Fixes Could you release a version that supports aarch64 #503

What the code does

• fixed GHA CI workflow to be runnable at all ..
• extends GHA CI workflow to use docker buildx
• adds build-and-push-multiarch-image and build-and-push-multiarch-zk-image targets in makefile and calls these targets in the GHA CI workflow when a release was created
• extends zookeeper-operator Dockerfile to be capable of multiarch builds, i.e. using TARGETOS and TARGETARCH
• leverages docker hub's capability of easily hosting mutliarch images

How to verify it

• created a new, public docker repo and used my pat tokens for this during build. Builds were published successfully
• release workflow was successful: https://github.com/mmoscher/zookeeper-operator/actions/runs/3237800915/jobs/5305287631
• test release was successfully build and pushed: https://hub.docker.com/r/mmoscher/zookeeper-operator/tags

[codecov]

Codecov Report

Base: 85.05% // Head: 85.05% // No change to project coverage 👍

Coverage data is based on head (814ff04) compared to base (ae23010).
Patch has no changes to coverable lines.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #504   +/-   ##
=======================================
  Coverage   85.05%   85.05%           
=======================================
  Files          12       12           
  Lines        1606     1606           
=======================================
  Hits         1366     1366           
  Misses        155      155           
  Partials       85       85           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[mmoscher]

@anishakj seem's that the commit singoffs are broken.

IMHO this is wrong.

If this PR is helpful at all, I would create a new one with a single commit introducing these changes.

[anishakj]

@mmoscher Have you verified the binary created for arm64

[mmoscher]

@anishakj nope not yet, since the build can only be done in the emulated docker platform, thus in the container itself.
Will check if the container can be validated. Any hints? How to you validate your builds? Thanks in advance!

[janhoy]

Status of this?

[mmoscher]

@janhoy sorry to say, but nothing new yet! Feel free to move on and submit PR's to my fork, if you like.
Maybe I will manage to free some time next week.

[derekm]

If the push target is obsolete now, should we just remove it?

[derekm]

Here you change the login target command-line to match the test-login command-line, but then you don't use it above in the GitHub Actions workflow during the publish. Does make login not work? Do we need to bind the secrets as environment variables before calling make login?

Here is an example of binding secrets to environment variables: https://github.com/pravega/pravega/blob/master/.github/workflows/gradle.yml#L152

[anishakj]

@mmoscher Have you verified the binary created for arm64

@mmoscher Could you please address the comments provided by @derekm