Closed godber closed 1 month ago
This happens when there's a new version of the base image (alpine in this case). The amd64 alpine images uses pre-built binaries so they build very fast but the other arch build node from source which takes lot longer. In order not to break tags, they get update as they are ready
Oh, that's interesting, thanks for the response. I guess that leaves me with the following questions:
Feel free to close this when you respond again or I'll just close if it stays open much longer. At least this gotcha is documented.
Node from source takes a long time (over an hour) and our queue was quite busy with the release of alpine 3.20. With that being said, some arch are having a separate issue and the progress is being tracked at https://github.com/docker-library/official-images/issues/16830
Is it expected to have different alpine versions on different platforms for the same alpine tag?
For instance, pulling the
node:22-alpine
image on theamd64
and then thearm64
platforms show different versions of alpine being used. See steps to reproduce below.Environment
Expected Behavior
I would expect the alpine versions to match.
Current Behavior
Currently they do not match
Possible Solution
Unsure yet.
Steps to Reproduce
Additional Information
If the alpine versions do not match, users who need
node-gyp
will encounter problems because the python version differs between alpine 3.19 and 3.20. Users will experience problems when doingimport gyp
... they will see errors that contain:It is possible to work around this problem by adding a line like this to their dockerfiles: