Skip to content

feat(miner-deployment): wire GITTENSORY_MINER_VERSION build-time metadata into both form factors #4310

Description

@JSONbored

The miner CLI already reports some version today — bin/gittensory-miner.js reads require("../package.json").version at startup (:57-59) and wires it to --version/-v/version (:80-87) via printVersion (packages/gittensory-miner/lib/cli.js:1-2: `${packageName}/${packageVersion} (node ${process.version})`). So this issue isn't adding version reporting from nothing — it's adding a build-time-injectable override, because that require() read is only ever correct for a laptop-mode npm install (where package.json really is what got installed). It will not necessarily be correct for the new fleet Docker image (sibling Phase 6 Dockerfile issue), which — like the main service — may get built from a commit/tag ahead of the last npm-published version.

Two real precedents already exist in this repo for two different ways to bake a version in, and this item most likely wants a combination:

  • packages/gittensory-engine/src/version.ts derives ENGINE_VERSION from its own package.json at compile time via a JSON module import (import ownPackageJson from "../package.json" with { type: "json" }) — shipped 2026-07-08. gittensory-miner has no build/bundle step today (its build script is just node --check over plain ESM files, confirmed in packages/gittensory-miner/package.json:34), so this exact pattern is directly usable without adding a bundler: a small lib/version.js exporting MINER_VERSION the same way.
  • The root Dockerfile instead threads a build-time-supplied value all the way to runtime: ARG GITTENSORY_VERSIONENV GITTENSORY_VERSION=${GITTENSORY_VERSION} (lines 6, 31-38), read at runtime in src/selfhost/sentry.ts:192 and src/selfhost/otel.ts:62 (env.GITTENSORY_VERSION, falling back to SENTRY_RELEASE) — this is how the main service's image asserts its actual built ref for observability/release tagging, independent of package.json. GITTENSORY_MINER_VERSION doesn't exist anywhere in the repo yet (confirmed by search); this issue is what introduces it, mirroring that same ARG/ENV shape for the new fleet Dockerfile (sibling Phase 6 issue).

Deliverables

  • packages/gittensory-miner/lib/version.js (or similar) exporting a MINER_VERSION constant read from the package's own package.json at import time, following gittensory-engine/src/version.ts's JSON-import pattern.
  • A GITTENSORY_MINER_VERSION environment-variable override: when set, it wins over the package.json-derived value — this is the piece that lets the fleet Docker image (sibling issue) assert its real build ref via ARG GITTENSORY_MINER_VERSIONENV, mirroring the root Dockerfile's GITTENSORY_VERSION handling.
  • Wire the resolved value into printVersion's output (packages/gittensory-miner/lib/cli.js) and into gittensory-miner status --json if that command reports a version field — so both form factors (laptop npm install, fleet Docker image) report a value that's actually correct for how they were built, not just always the npm package.json.
  • Unit tests covering both paths: no env override (falls back to package.json version) and an env override present (wins).

References

  • packages/gittensory-engine/src/version.ts — the compile-time JSON-import pattern to mirror for a MINER_VERSION constant.
  • Dockerfile (repo root) lines 6, 31-38 — the ARG/ENV GITTENSORY_VERSION threading pattern to mirror for GITTENSORY_MINER_VERSION.
  • src/selfhost/sentry.ts:192, src/selfhost/otel.ts:62 — where the main service actually reads its env-supplied version at runtime, for the equivalent read-site pattern.
  • packages/gittensory-miner/bin/gittensory-miner.js:57-59,80-87, packages/gittensory-miner/lib/cli.js:1-2 (printVersion) — the existing (package.json-only) version-reporting code path this issue extends.
  • packages/gittensory-miner/package.json:34 — confirms no build/bundle step exists yet, so the compile-time JSON-import approach needs no new tooling.

Metadata

Metadata

Assignees

No one assigned

    Labels

    gittensor:featureGittensor-scored feature linked to a feature issue — scores a 0.25x multiplier.help wantedExtra attention is needed

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions