Haskell stack does not support ARM64

[AlistairB]

Hi, I am working on adding ARM64 support to the Haskell images. Unfortunately Haskell stack does not support ARM64. I have pinged the maintainers and there is interest in adding this support, but no actual movement.

I would prefer not to hold back the images because of stack lacking this support, so I would like to exclude stack on ARM64. As such I am making a change to the stack test so that it will gracefully skip on ARM64.

I will make this clear in the docs with a follow up PR once everything is ready to go.

Actually, I could wait until ARM64 support for Haskell images is ready for release and include that in this PR if you want. However, I wanted to get feedback to see if this solution would be acceptable.

[tianon]

We don't actually run the test suite on other architectures (unless we have a reason to, like a maintainer requesting it for an architecture they don't have access to test on), so if the images still build successfully I don't think this is actually necessary. If the images fail to build, I'd suggest that we instead remove arm64v8 from library/haskell (which, it's not listed yet, so we're not even trying to build the image on arm64v8 yet). 👍 😄

[AlistairB]

Ah I see thanks. I will likely request that we do test arm64v8 for haskell if possible as we don't have a good way to test this in CI on the docker-haskell repo (I am trying to set up drone.io, but struggling to get my account approved..). Is enabling this something I can PR?

I'm looking to add arm64v8 as of this pr. So I'll add that update to this PR including adding arm64v8.

[tianon]

Sorry, I guess I was a little ambiguous there -- the only place the tests run in an automated way is the GitHub Actions in this repository as a smoke test for image updates (and in the same way in many of the individual image repositories to pre-test them before presenting the updates here), and since GitHub Actions only supports amd64 (and Windows), that's the only variant of the tests that ever runs automatically.

If you want to make sure the build totally fails if something you're downloading, like stack itself, doesn't run at all, then I'd suggest adding a basic smoke test like stack --version to the execution lines in the Dockerfile itself (we've caught an embarrassing number of really minor issues that way 😅). See https://github.com/docker-library/golang/blob/730087d32b6bcc3710d3225e9d4891f8a7ba6223/1.17/bullseye/Dockerfile#L122 for a simple example.

What we've done in the past upon request is a one-off test build (by hand) on one of the real architecture systems we have. In that PR, version 'GLIBC_2.29' not found sounds like the stack binary was built against a newer version of glibc though, so probably not related to emulation issues (ie, not likely something that would be fixed by running on "real" hardware). 😅

[AlistairB]

Ah I see, thanks for the detailed explanation!

Actually, I have managed to cobble together a wacky emulated test via https://github.com/uraimo/run-on-arch-action which seems to work ok.

If you want to make sure the build totally fails if something you're downloading, like stack itself, doesn't run at all, then I'd suggest adding a basic smoke test like stack --version to the execution lines in the Dockerfile itself (we've caught an embarrassing number of really minor issues that way sweat_smile). See https://github.com/docker-library/golang/blob/730087d32b6bcc3710d3225e9d4891f8a7ba6223/1.17/bullseye/Dockerfile#L122 for a simple example.

Good call, actually I have largely copied the pattern from the golang images to support arm64 including the version technique which is really nice 😆

Anyway, I will close this as these will only run on amd64 as noted. Cheers.