From 5d3d9fb8c3afd181813f0a2dc577dcd9e27d9477 Mon Sep 17 00:00:00 2001 From: Wynne Pirini Date: Wed, 14 Oct 2026 18:39:48 +1300 Subject: [PATCH] docs(ns8): install from :edge; :latest is still the unusable first build 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. --- packaging/ns8/README.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/packaging/ns8/README.md b/packaging/ns8/README.md index ef3aedc0..c671f2e7 100644 --- a/packaging/ns8/README.md +++ b/packaging/ns8/README.md @@ -30,13 +30,20 @@ Key facts: On the cluster leader, as root: ``` -add-module ghcr.io/calnode/ns8-calnode:latest 1 +add-module ghcr.io/calnode/ns8-calnode:edge 1 ``` Replace `calnode` with the actual registry namespace if you built your own image (see Development). The command prints the instance name, usually `ns8-calnode1`. +> **Use `:edge`, not `:latest`.** This module has not had a release tag yet, so +> `:latest` still points at the first build, which predates the fixes for a +> missing `create-module` action, non-executable action scripts and an +> invalid schema pattern. That build fails at `add-module`. `:latest` becomes +> usable at the next module release, at which point a pinned version tag +> (`ghcr.io/calnode/ns8-calnode:0.10.2`, say) is the better thing to install. + Then configure it with your public hostname: ``` @@ -116,8 +123,9 @@ tag pushes, mirroring the app tags in `docker-publish.yml`: - push a `vX.Y.Z` tag pushes module `:X.Y.Z`, `:X.Y` and `:latest`, running app `:X.Y.Z`, so a module release always runs the matching app release -Because `:latest` only moves on a release tag, use `:edge` to try the newest -module on a test cluster. +Because `:latest` only moves on a release tag, and no module release has been +cut yet, `:latest` is currently unusable (see Install). Use `:edge` until the +first module release lands. Every published module tag is a **multi-arch** manifest (amd64 + arm64). NS8 runs modules as rootless containers on the node, so a single-arch image would @@ -142,7 +150,7 @@ source of truth; nothing is stamped at build time. Running the test suite needs an NS8 test cluster; see the [NS8 testing docs](https://github.com/NethServer/ns8-github-actions/blob/v1/README.md#running-tests-locally). -From this directory: `run-ns8-tests ghcr.io/calnode/ns8-calnode:latest`. +From this directory: `run-ns8-tests ghcr.io/calnode/ns8-calnode:edge`. Not yet run in CI: no test cluster is wired up. ## UI translation