Repository navigation
docs(ns8): install from :edge; :latest is still the unusable first build - #140
Conversation
The module has never had a release tag, so :latest still points at the very first published build (digest sha256:01ceca48), which predates the fixes for the missing create-module action, the non-executable action scripts and the invalid schema pattern. That build fails at add-module, so anyone following the install instructions was getting a broken module. Note the root cause is timing, not a broken tag scheme: :latest moves on a release tag, and no release has been cut since the module was added. There are no installs in the wild to strand, this is a docs-accuracy fix.
![pullfrog[bot]](https://avatars.githubusercontent.com/in/1768019?s=60&v=4){kind=small}
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
A docs-only correction to packaging/ns8/README.md: the documented NS8 install command has been switched from ns8-calnode:latest to ns8-calnode:edge, with a note explaining that :latest is stranded at the first build because no module release tag has been cut yet.
- Install command →
:edge—add-module ghcr.io/calnode/ns8-calnode:edge 1, which is the correct working tag today. - Explanatory note — states why
:latestfails atadd-module(it predates thecreate-moduleaction, executable action scripts, and the RE2-safe schema pattern) and what changes at the first module release. - Development section +
run-ns8-tests— aligned to:edge.
I verified the load-bearing claims against the live registry rather than trusting the description:
:latestresolves tosha256:01ceca48…(matching the PR body), is single-arch amd64, labelsorg.nethserver.images=ghcr.io/calnode/calnode:0.10.1, created2026-09-29— i.e. the 0.10.1 first build, pre-fixes.:edgeexists as a multi-arch (amd64+arm64) index created2026-10-14T04:45Z, one minute after #139 merged, labelledghcr.io/calnode/calnode:edge— so it carries the #135/#137/#138/#139 fixes.- The tag scheme in the note matches
.github/workflows/ns8-module.ymlexactly.
The premise holds and the guidance is accurate. The 0.10.2 version in the note reads as a deliberate illustrative example ("say"); no change requested. Worth noting for a future docs pass (not this PR): line 10 describes the wrapped app image as ghcr.io/calnode/calnode:latest, whereas published module images label the matching app tag (:0.10.1 for :latest, :edge for :edge).
deepseek-v4.1-flash ｜ 𝕏
1 participant
The module README told admins to install from
:latest, but the module has never had a release tag, so:lateststill points at the first published build (digestsha256:01ceca48). That build predates the four fixes in #135 and #137 to #139: nocreate-moduleaction, non-executable action scripts, an invalid schema pattern, and a hardcoded app tag. It fails atadd-module.So the documented install command did not work. Now points at
:edge, which is the moving tag for the newest verified build, with a note explaining why and what will change at the first module release.The
run-ns8-testsline and the Development section were updated to match.Root cause is timing rather than a broken tag scheme:
:latestmoves on a release tag and none has been cut since the module was added, so nothing is stranded in the wild. The durable fix is the first module release.