Latest release (3.1.1) missing arm64 docker images

[felixb]

Bug description

While 3.1.0 was still available as arm64 and amd64 docker image, the 3.1.1 release is only available for amd64.
Thus the deployment on arm64 CPUs (e.g. AWS graviton) fails.

There are quite some similar issues here already referring to developer images for apple's CPUs.
The workaround given for those won't work on k8s clusters running on arm64 nodes.

How to reproduce the bug

1. Check out the listed architectures for the release docker image: https://hub.docker.com/r/apache/superset/tags?page=1&name=3.1.1

Screenshots/recordings

No response

Superset version

3.1.1

Python version

3.9

Node version

16

Browser

Chrome

Additional context

No response

Checklist

• I have searched Superset docs and Slack and didn't find a solution to my problem.
• I have searched the GitHub issue tracker and didn't find a similar bug report.
• I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

[mistercrunch]

Oh I think this is related to the branch being cut prior to the multi-platform changes in master. Hoping the 4.x cuts will include what's need in the branch itself.

To remedy this for that branch I just triggered the workflow dispatched manually from master. Oh, and I had to cherry-pick 0cd2431989 the same way I had done in 3.1.0 and somehow didn't make the cut for 3.1.1 (I never told anyone I squeezed in this cherry, thinking it was pretty minor, hard to explain change). That cherry is bringing a newer Dockerfile that prevents a race condition that happens when dual-platform building in parallel (both docker build processes fight for locally-mounted apt-get work folders, which we move away from that approach in that newer dockerfile)

@michael-s-molina I know it's not super clean, but I moved the tag 3.1.1 to include that cherry. How do we make sure it gets picked in 3.1.2+?

[mistercrunch]

For the record, job is running here -> https://github.com/apache/superset/actions/runs/8150387426/job/22276578594

Explaining a bit more the intricacy of the difference between a release GHA trigger and and workflow_dispatch on master... The former will use the old GHAs defined in the branch, while the master trigger will use the GHA definitions on master, pull the right old branch/tags, and run the newer master build command against that old tag. Subtle difference, but the reason for the issue here... For older release/re-release, we'll have to manually dispatch from master as such:

Moving forward, it shouldn't be an issue, unless we want to retroactively change some of the logic, say if we wanted to introduce a third build platform retroactively, we'd have to fiddle with things, trigger from master, ...

[mistercrunch]

I think we should be able to close this once the job finishes and we confirm that:

• 3.1.1 is all multi-platform
• we'll pick that cherry moving forward
• we'll trigger manual runs for 3.x releases :(

We could create a cherry with fresher actions, but hoping we can just move on with our lives to 4.x

[michael-s-molina]

I think we should be able to close this once the job finishes and we confirm that:

3.1.1 is all multi-platform

https://hub.docker.com/r/apache/superset/tags?page=1&name=3.1.1

we'll pick that cherry moving forward

Added #26205 as a cherry for 3.1.

we'll trigger manual runs for 3.x releases :(

Will do.

[michael-s-molina]

@mistercrunch I tried to manually build 3.1.2 but I'm getting errors:

[mistercrunch]

Ok I'm on it!

[mistercrunch]

Ok I opened a PR fixing it and the dockers should be published