Add arm64 builds

[benmoss]

What this PR does / why we need it:

• Switch to using docker buildx for building through kbld for multi-arch support

Which issue(s) this PR fixes:

Fixes #573

Does this PR introduce a user-facing change?

Adds support for arm64 in the kapp-controller image

Additional Notes for your reviewer:

Review Checklist:

• Follows the developer guidelines
• Relevant tests are added or updated
• Relevant docs in this repo added or updated
• Relevant carvel.dev docs added or updated in a separate PR and there's
  a link to that PR
• Code is at least as readable and maintainable as it was before this
  change

Additional documentation e.g., Proposal, usage docs, etc.:

[joe-kimmel-vmw]

i left you some annoying comments but this seems fine and I appreciate you taking it on

[benmoss]

• Test release from my fork built here: https://github.com/benmoss/carvel-kapp-controller/runs/6817310991
• Multi-arch image from that build: https://github.com/benmoss/carvel-kapp-controller/pkgs/container/carvel-kapp-controller/24748131?tag=rand-1654793952642415300-6418976100130-kapp-controller
• release: https://github.com/benmoss/carvel-kapp-controller/releases/tag/v0.37.14

[neil-hickey]

LGTM, you have my stamp of approval ⭐

[DennisDenuto]

Really cool stuff here!

• Test release from my fork built here: https://github.com/benmoss/carvel-kapp-controller/runs/6817310991

Nice! I was wondering how you tested / iterated on this.

I am assuming that the upgrade-testing gh-action job is to test folk upgrading to the freshly cut release? If that is the case, can you update (on your fork) the upgrade-test to use the release produced on your fork? (Just to get added reassurance that the release.yaml produced in your fork results in a successful deploy)

https://github.com/vmware-tanzu/carvel-kapp-controller/blob/0726f760ad4f5685d7d9aab123d4732726e8b2cd/.github/workflows/upgrade-testing.yml#L40

Also, along this train of thought... and this suggestion probably makes way more sense to implement in a different PR, should we be adding upgrade-tests for arm deployments in addition to amd64, now that we produce images for both?

[benmoss]

Nice! I was wondering how you tested / iterated on this.

The main thing I needed to do was change image_repo from config/release to my github repo's GHCR, which I did by allowing --data-values-env=KCTRL and then overriding it in my fork to just be relative to the current repo. It would be nice if this wasn't hard-coded in this repo.

Other than that just enabling GitHub actions on my fork and pushing tags is all you need to do. Just be extra paranoid that you're not pushing to this repo :). I'll usually just be explicit and git push fork develop instead of git push.

I am assuming that the upgrade-testing gh-action job is to test folk upgrading to the freshly cut release? If that is the case, can you update (on your fork) the upgrade-test to use the release produced on your fork? (Just to get added reassurance that the release.yaml produced in your fork results in a successful deploy)

Yeah, I could definitely set this up.

Also, along this train of thought... and this suggestion probably makes way more sense to implement in a different PR, should we be adding upgrade-tests for arm deployments in addition to amd64, now that we produce images for both?

Yeah, I was thinking we maybe want to run tests against an arm-deployed cluster. Will have to play around with that arm runner and see how well that works with minikube or what our other options would be.

[benmoss]

Actually I don't think I understand your suggestion of running the upgrade tests from my release.. What would we be upgrading to? The test-gh and Kind Cluster E2E tests jobs test that this PR deploys successfully.

I think what you're describing is something like us generating a release.yml for every PR and just deploy/e2e that. I like the idea, I've been trying to think of how we could automate exercising our release process especially for work like this.

EIther way this build should test against my release.yml.

[DennisDenuto]

EIther way this build should test against my release.yml.

Yeah, seeing a successful deploy of the generated release.yaml based on your fork is what I was after. Alternatively a manual test using that release.yaml and seeing it succeed would also have given me that same level of confidence.

I think what you're describing is something like us generating a release.yml for every PR and just deploy/e2e that. I like the idea, I've been trying to think of how we could automate exercising our release process especially for work like this.

+1

this PR LGTM! 🚀