Latest release (3.1.1) missing arm64 docker images

apache / superset

Apache Superset is a Data Visualization and Data Exploration Platform

https://superset.apache.org/

Apache License 2.0

62.78k stars 13.87k forks source link

Latest release (3.1.1) missing arm64 docker images #27378

Closed felixb closed 8 months ago

felixb commented 8 months ago

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

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

Browser

Chrome

Additional context

No response

Checklist

[ ] I have searched Superset docs and Slack and didn't find a solution to my problem.
[X] 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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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