Adopts build-argument syntax in the template service definition +
template Dockerfile to pass an image tag plus an optional list of
extra packages to the Dockerfile at build time.
Pinning to a specific base image can now be accomplished in the Compose
file. This places Node-RED on equal footing with containers that do not
use local Dockerfiles (and Mosquitto which already has similar
build-argument syntax).
Together, the changes mean user customisations to the first part of the
Dockerfile are no longer at risk of being overwritten by menu runs to
change the list of add-on nodes.
For any given IOTstack installation, there is some possibility of a
hybrid result, depending on how and when the user runs the menu, or
which techniques each user employs to manage their Compose file and
Node-RED Dockerfile. The intention is to either fail safe or at least
fail sensibly:
old Compose + old Dockerfile = no change.
old Compose + new Dockerfile will adopt latest so node.jsmay
change from 12.x to 14.x on the next --build but this will depend on
whether the user ever explicitly set latest-14 in their old Dockerfile.
new Compose + old Dockerfile = no change. The service definition build
arguments will be ignored and the user may be confused until consulting
the documentation, but the container will still build as before.
new Compose + new Dockerfile will behave as per the revised
documentation. Absent any user changes to the service definition, the
resulting container will be based on latest (which implies node.js
14.x) and there will no packages other than eudev-dev (the existing
Dockerfile default).
Worst case is an existing user adopting all-new syntax without realising
the old Dockerfile specified latest-12, thereby advancing to node.js
14.x unexpectedly, perhaps also losing additional packages along the
way. The fix is to specify DOCKERHUB_TAG=latest-12, append any lost
packages to EXTRA_PACKAGES=, and rebuild.
Personally, I switched to -14 a good six months ago. It worked
out-of-the-box with zero migration issues and I've never looked back.
While that's only n=1, I don't feel there's sufficient risk to warrant
IOTstack continuing to default to -12. We have to change sometime, or
we'll be back where we were when images based on -10 were no longer
being offered as Node-RED marched forward.
Using node.js version 14 is the implicit recommendation (ie latest
and latest-14 are currently synonyms). Version 16 is available but is
known to throw up some migration issues. IOTstack started defaulting to
version 12 in March 2021 (when version 10 was deprecated).
Adopts build-argument syntax in the template service definition + template Dockerfile to pass an image tag plus an optional list of extra packages to the Dockerfile at build time.
Pinning to a specific base image can now be accomplished in the Compose file. This places Node-RED on equal footing with containers that do not use local Dockerfiles (and Mosquitto which already has similar build-argument syntax).
Together, the changes mean user customisations to the first part of the Dockerfile are no longer at risk of being overwritten by menu runs to change the list of add-on nodes.
For any given IOTstack installation, there is some possibility of a hybrid result, depending on how and when the user runs the menu, or which techniques each user employs to manage their Compose file and Node-RED Dockerfile. The intention is to either fail safe or at least fail sensibly:
latestsonode.jsmay change from 12.x to 14.x on the next--buildbut this will depend on whether the user ever explicitly setlatest-14in their old Dockerfile.latest(which impliesnode.js14.x) and there will no packages other thaneudev-dev(the existing Dockerfile default).Worst case is an existing user adopting all-new syntax without realising the old Dockerfile specified
latest-12, thereby advancing tonode.js14.x unexpectedly, perhaps also losing additional packages along the way. The fix is to specifyDOCKERHUB_TAG=latest-12, append any lost packages toEXTRA_PACKAGES=, and rebuild.Personally, I switched to
-14a good six months ago. It worked out-of-the-box with zero migration issues and I've never looked back. While that's only n=1, I don't feel there's sufficient risk to warrant IOTstack continuing to default to-12. We have to change sometime, or we'll be back where we were when images based on-10were no longer being offered as Node-RED marched forward.Using
node.jsversion 14 is the implicit recommendation (ielatestandlatest-14are currently synonyms). Version 16 is available but is known to throw up some migration issues. IOTstack started defaulting to version 12 in March 2021 (when version 10 was deprecated).Signed-off-by: Phill Kelley 34226495+Paraphraser@users.noreply.github.com