Propagate package version into cluster-reported version

[pimlock]

Context

During troubleshooting, someone installed the package via pip, but the cluster-reported version was still the default 0.1.0.

A follow-up note suggests the cluster-side version may currently be hardcoded and should likely be passed through as a build argument.

Problem

The cluster version shown at runtime can be incorrect, which makes debugging and support harder.

Expected behavior

The version reported by the cluster should match the version used to build and publish the artifact (for example, the pip package version).

Proposed direction

• Trace how version metadata is produced during build and publish.
• Propagate the real version into cluster artifacts and runtime (for example via build args or generated metadata).
• Remove any hardcoded fallback that masks the actual build version.

Acceptance criteria

• Installing a non-0.1.0 package no longer reports 0.1.0 by default.
• Cluster version output matches the artifact and package version.
• Add automated coverage for the version propagation path (unit/integration as appropriate).

[pimlock]

🏗️ build-plan

Implementation Plan

Issue type: fix
Complexity: Medium
Confidence: High — root cause and required build-path changes are now clear

Summary

The cluster-reported version comes from navigator-server's compile-time CARGO_PKG_VERSION, but the Docker build path for server/cluster artifacts does not propagate the computed release cargo version (unlike wheel/CLI build paths). We will propagate one version source through component image builds and cluster chart packaging so deployed clusters report the artifact version instead of falling back to 0.1.0, while still publishing latest alongside the explicit version tag.

Scope

• deploy/docker/Dockerfile.server: accept NEMOCLAW_CARGO_VERSION and patch [workspace.package].version before building navigator-server.
• tasks/scripts/docker-build-component.sh: forward NEMOCLAW_CARGO_VERSION as a build arg for Rust component images without disturbing existing cache scope inputs.
• tasks/scripts/docker-publish-multiarch.sh: compute cargo version once, publish the same image as both latest and the explicit version tag, and pass the version into server/sandbox image builds.
• tasks/scripts/docker-build-cluster.sh, deploy/kube/manifests/navigator-helmchart.yaml, deploy/docker/cluster-entrypoint.sh: stop relying on hardcoded navigator-0.1.0.tgz; inject/use the packaged chart version dynamically.
• .github/workflows/docker-build.yml and .github/workflows/publish.yml: ensure CI/publish builds pass the same computed cargo version into Docker build paths.

Implementation Steps

1. Add a single NEMOCLAW_CARGO_VERSION flow through Docker component build scripts and Dockerfile.server, mirroring existing wheel build behavior and preserving current layer/cache scope behavior.
2. Make cluster chart selection/version wiring dynamic (chart filename + checksum lookup) rather than hardcoded 0.1.0.
3. Update CI/publish workflows so release builds publish both latest and the explicit version tag, while using the same computed cargo version for Docker and Python artifacts.
4. Validate end-to-end that a non-0.1.0 build reports a matching version via nemoclaw cluster status, and confirm cache-sensitive paths (buildx layer cache / sccache inputs) remain unchanged apart from intended final-artifact invalidation.

Test Plan

• Unit tests: Add/extend tests for any new helper functions introduced for version/tag/chart resolution (if implemented in Rust).
• Integration tests: Build server + cluster images with a synthetic version (for example 0.1.1-dev.0), deploy locally, and assert health endpoint/cluster status reports that version.
• E2E tests: N/A unless e2e/ files are modified.

Risks & Open Questions

• If chart filename/version handling changes, we must avoid breaking deploys that still have older static chart paths cached.
• We should keep version-specific build args out of dependency-only cache warmup layers wherever possible so artifact correctness improves without degrading build performance.

Documentation Impact

• Update architecture/build-containers.md to describe version propagation for server binaries and cluster chart artifacts, including dual-tag publishing (latest + explicit version).

---

Revision 2 — incorporated feedback on dual-tag publishing and cache preservation
Revision 1 — initial plan

[pimlock]

🏗️ build-from-issue-agent

Let's tag the image with the version tag as well as latest.

Make sure that the layer caching (and potentially other caching, like rust/sccache) is not impacted by this change.

Agreed. I updated the plan to keep latest while also publishing and wiring the explicit version tag through the cluster build path.

I also tightened the implementation notes so version propagation does not leak into cache keys unnecessarily: the existing layer/buildx cache scopes and Rust/sccache configuration should remain stable, and verification will include checking that we only add explicit version build args where they affect the final artifact metadata rather than dependency-cache priming.

[pimlock]

🏗️ build-from-issue-agent

Implementation Complete

PR: #164

What was built

The Docker and cluster packaging paths now receive the computed package version so deployed clusters stop reporting the default workspace version. Cluster publish flows now keep latest and the explicit version tag aligned, and the cluster image resolves the packaged chart filename dynamically instead of hardcoding 0.1.0.

Tests

• Unit: N/A
• Integration: built server and cluster images with synthetic/computed versions and verified embedded version/chart packaging
• E2E: N/A

Docs updated

• architecture/build-containers.md

The issue will auto-close when the PR is merged.

[pimlock]

Confirmed it prints the version now:

nemoclaw status
Server Status

  Cluster: testing-migration
  Server: https://127.0.0.1:8080
  Status: Connected
  Version: 0.5.1-dev.55+g081fca9ae