Move ci to buildx for multiarch images #231
Conversation
byrnedo
changed the title
|
ah damn, I just realised that there's possibly no actual debian openresty armv7 package for instance... |
|
The reason for the architecture suffix is to identify them for the manifest step. If all of it works without them, then I think that's OK? I never advertised them, so any compatibility issue is people's own problem. Plus they should use tagged releases, of which these would be a new tag. There are two kinds of images, built-from-source and built-from-upstream. If there's no architecture release upstream, we obviously can't support it directly. We can try still try to build it from source, but the QA level is different. It looks like |
|
Ok good, might make things a bit simpler. Well I got it to build and run locally last night from source but it took absolutely ages. Would running any aspect of openresty confirm if luajit is working? Or would I have to have it evaluate some custom lua code to know? |
|
Perhaps you can start with looking at LuaJIT itself and running its test suite in isolation. You should use OpenResty's fork. I'm curious what your hardware is. |
|
I ran the build last night on a raspberry-pi 2b and then cross compiled on my mac M1 and both 'seem to work'. Ok yeah, good idea, can try that. |
|
In searching for it I also found this for OpenResty Have you tried the |
|
It takes about 2-3 hours to build using qemu, including architectures linux/amd64, linux/arm64, linux/s390x, linux/ppc64le, linux/arm/v7 Issue: |
@neomantra Hi again.
Is it vital that openresty images keep the arch suffix on the image names? Would it be ok to skip those?