Skip to content

Propagate package version into cluster-reported version #159

Closed
#164
Closed
Propagate package version into cluster-reported version#159
#164
Labels
state:agent-readyApproved for agent implementationstate:pr-openedPR has been opened for this issue

Description

@pimlock
pimlock
opened on Mar 6, 2026

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).

Activity

  1. pimlock
    added
    bug
    on Mar 6, 2026

  2. pimlock commented on Mar 6, 2026

    @pimlock
    pimlock
    on Mar 6, 2026
    CollaboratorAuthor

    🏗️ 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

  3. pimlock
    added
    state:review-readyReady for human review
    on Mar 6, 2026

  4. pimlock commented on Mar 7, 2026

    @pimlock
    pimlock
    on Mar 7, 2026
    CollaboratorAuthor

    🏗️ 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.

  5. pimlock
    added
    state:agent-readyApproved for agent implementation
    state:in-progressWork is currently in progress
    and removed
    state:review-readyReady for human review
    on Mar 7, 2026
  6. pimlock
    added a commit that references this issue on Mar 7, 2026

    fix(build): propagate packaged version through cluster artifacts

    1b0bdc2

  7. pimlock commented on Mar 7, 2026

    @pimlock
    pimlock
    on Mar 7, 2026
    CollaboratorAuthor

    🏗️ 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.

  8. pimlock
    added
    state:pr-openedPR has been opened for this issue
    and removed
    state:in-progressWork is currently in progress
    on Mar 7, 2026
  9. pimlock
    closed this as completedin #164on Mar 7, 2026

  10. pimlock commented on Mar 7, 2026

    @pimlock
    pimlock
    on Mar 7, 2026
    CollaboratorAuthor

    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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    state:agent-readyApproved for agent implementationstate:pr-openedPR has been opened for this issue

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions