feat(devcontainer): bake velero CLI into the toolbox, pinned to prod server v1.18.2 #143

Merged
jakman85 merged 1 commits from feat/devcontainer-velero-cli into main 2026-11-08 05:30:29 +00:00
Owner

Adds the velero CLI to the pinned dev toolbox so operators can run velero backup describe/logs/get through ./infra/devcontainer/dev.sh run .... Before this change, command -v velero in the toolbox found nothing (measured 2026-11-07).

Changes

  • infra/devcontainer/versions.env: VELERO_VERSION=1.18.2. Lockstep with the server. The CLI and server are version-coupled. I checked the live version read-only: kubectl --context k3s-prod -n velero get deploy velero shows docker.io/velero/velero:v1.18.2, and HelmRelease velero is at chart 12.2.3. The pin has no renovate marker on purpose: bump it in the same PR as any velero chart bump that moves the appVersion, never on its own.
  • infra/devcontainer/Containerfile: release tarball from vmware-tanzu/velero (same style as flux/helm; no checksum, like every other tool in this file), recorded in /etc/dev-toolchain-versions. In the verify stage, velero is added to the PATH loop and check velero v${VELERO_VERSION} asserts the output of velero version --client-only.
  • infra/devcontainer/build-image.sh: VELERO_VERSION added to BUILD_ARGS. CI picks it up generically through --print-build-args.
  • README tool table, plus a short read-only CLI example in runbooks/backup-failure.md.
  • Handoff: decisions/2026-11-07-devcontainer-velero-cli.md.

Sensitive paths: none touched. No .gitea/**, no ci/**.

Verification

  • Local image build: IMAGE=localhost/home-k3s-dev:velero-wt ./build-image.sh returned rc 0. The verify stage printed ok velero and ok velero v1.18.2, then TOOLBOX VERIFIED. The image was not pushed.
  • Read-only prod smoke test with that image: velero version shows Client v1.18.2 and Server v1.18.2. velero backup get lists the daily backups, all Completed with 0 errors.
  • Toolbox gate (worktree, DEV_KUBECONFIG=/dev/null, ENGINE shim mounting .git and the spec repo with SPEC_REPO), HEAD 60e3a24: rc 3 (UNDETERMINED).
    • Passed: spec-immutability, lint, l0, l1, render-golden, decisions-log, approval-policy.
    • Did not run: gitea-settings (no SETTINGS_API_TOKEN, expected locally).
    • conformance (L2/L3) is SKIPPED because CLUSTER_AVAILABLE is unset, which is expected.

Found while testing (report only, not fixed)

Every daily backup since velero-daily-20261031030050 has 1 warning:
gitea-actions: /pods act-runner-5944dfdfb8-69bvq — Skip pod volume data error: pod is not in the expected status ... phase=Failed: pod is not running.
gitea-actions holds 11 Evicted (Failed) pods from the old ReplicaSet act-runner-5944dfdfb8, ten of them from 2026-10-30T08:26Z. Removing them is an operator action.

🤖 Generated with Claude Code

Adds the `velero` CLI to the pinned dev toolbox so operators can run `velero backup describe/logs/get` through `./infra/devcontainer/dev.sh run ...`. Before this change, `command -v velero` in the toolbox found nothing (measured 2026-11-07). ## Changes - `infra/devcontainer/versions.env`: `VELERO_VERSION=1.18.2`. **Lockstep with the server.** The CLI and server are version-coupled. I checked the live version read-only: `kubectl --context k3s-prod -n velero get deploy velero` shows `docker.io/velero/velero:v1.18.2`, and HelmRelease velero is at chart `12.2.3`. The pin has **no renovate marker on purpose**: bump it in the same PR as any `velero` chart bump that moves the appVersion, never on its own. - `infra/devcontainer/Containerfile`: release tarball from vmware-tanzu/velero (same style as flux/helm; no checksum, like every other tool in this file), recorded in `/etc/dev-toolchain-versions`. In the verify stage, `velero` is added to the PATH loop and `check velero v${VELERO_VERSION}` asserts the output of `velero version --client-only`. - `infra/devcontainer/build-image.sh`: `VELERO_VERSION` added to `BUILD_ARGS`. CI picks it up generically through `--print-build-args`. - README tool table, plus a short read-only CLI example in `runbooks/backup-failure.md`. - Handoff: `decisions/2026-11-07-devcontainer-velero-cli.md`. **Sensitive paths: none touched.** No `.gitea/**`, no `ci/**`. ## Verification - **Local image build:** `IMAGE=localhost/home-k3s-dev:velero-wt ./build-image.sh` returned rc 0. The verify stage printed `ok velero` and `ok velero v1.18.2`, then `TOOLBOX VERIFIED`. The image was not pushed. - **Read-only prod smoke test with that image:** `velero version` shows Client v1.18.2 and Server v1.18.2. `velero backup get` lists the daily backups, all Completed with 0 errors. - **Toolbox gate** (worktree, `DEV_KUBECONFIG=/dev/null`, ENGINE shim mounting `.git` and the spec repo with `SPEC_REPO`), HEAD 60e3a24: **rc 3 (UNDETERMINED)**. - Passed: spec-immutability, lint, l0, l1, render-golden, decisions-log, approval-policy. - Did not run: `gitea-settings` (no `SETTINGS_API_TOKEN`, expected locally). - `conformance` (L2/L3) is SKIPPED because `CLUSTER_AVAILABLE` is unset, which is expected. ## Found while testing (report only, not fixed) Every daily backup since `velero-daily-20261031030050` has **1 warning**: `gitea-actions: /pods act-runner-5944dfdfb8-69bvq — Skip pod volume data error: pod is not in the expected status ... phase=Failed: pod is not running`. `gitea-actions` holds 11 Evicted (`Failed`) pods from the old ReplicaSet `act-runner-5944dfdfb8`, ten of them from 2026-10-30T08:26Z. Removing them is an operator action. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
gitea-admin added 1 commit 2026-11-08 05:22:56 +00:00
feat(devcontainer): bake velero CLI into the toolbox, pinned to prod server v1.18.2
gate / gate (pull_request) Successful in 3m1s
gate / conformance (pull_request) Skipped
images / images (pull_request) Successful in 44s
60e3a24652
The velero CLI and server are version-coupled, so VELERO_VERSION follows the
server running on prod (docker.io/velero/velero:v1.18.2, chart 12.2.3,
verified 2026-11-07). It has no renovate marker on purpose: bump it together
with the chart's appVersion. The verify stage asserts that
`velero version --client-only` reports the pin. The build arg reaches CI
through build-image.sh --print-build-args, so no .gitea/ or ci/ change is
needed.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
jakman85 merged commit dd94101647 into main 2026-11-08 05:30:29 +00:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Home-Network/home-network-k3s-impl#143