jakman85andClaude Opus 5.5
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]>
3.5 KiB
3.5 KiB
date, branch, title
| date | branch | title |
|---|---|---|
| 2026-11-07 | feat/devcontainer-velero-cli | Bake the velero CLI into the dev toolbox, pinned to the prod server version |
What changed
infra/devcontainer/versions.env: newVELERO_VERSION=1.18.2, with a comment explaining that the CLI and server are version-coupled, so this pin follows the server and is not bumped on its own. It has no# renovate:marker on purpose. When avelerochart bump inplatform/velero/helmrelease.yamlchanges the appVersion, bump this pin in the same PR.infra/devcontainer/Containerfile:ARG VELERO_VERSION; the binary comes from the vmware-tanzu GitHub release tarball and is installed in the same RUN as flux/helm. There is no checksum check, which matches the other tools in that file (none of them verify one).velero=is recorded in/etc/dev-toolchain-versions. The verify stage now checks thatvelerois on PATH, andcheck velero v${VELERO_VERSION}asserts the output ofvelero version --client-only.infra/devcontainer/build-image.sh:VELERO_VERSIONadded toBUILD_ARGS. CI reads that list generically through--print-build-args(.gitea/workflows/scripts/images.sh), so no sensitive path (.gitea/**,ci/**) was touched.infra/devcontainer/README.md: added a Backups row to the tool table.runbooks/backup-failure.md: under "First commands", a read-onlyvelero backup describe --details/backup logsexample run through dev.sh.
What I verified
- Live server version, read-only:
kubectl --context k3s-prod -n velero get deploy veleroshows imagedocker.io/velero/velero:v1.18.2, and HelmReleasevelerohas lastAttemptedRevision12.2.3. - Local build:
IMAGE=localhost/home-k3s-dev:velero-wt ./build-image.shreturned rc 0. The verify stage printedok velero(on PATH),ok velero v1.18.2(pin check) andTOOLBOX VERIFIED. The image was built under a separate local tag and not pushed. - Smoke test with that image against prod (read-only):
velero versionreports Client v1.18.2 and Server v1.18.2.velero backup getlists the daily backups, allCompletedwith 0 errors. - Recurring warning (reported only, not fixed): every daily backup since
velero-daily-20261031030050has 1 warning. Backups up to 20261030 have 0. The warning text is:gitea-actions: resource: /pods name: /act-runner-5944dfdfb8-69bvq message: /Skip pod volume data error: /pod is not in the expected status, ... phase=Failed: pod is not running. It is the same pod in 20261031, 20261104 and 20261108.gitea-actionsholds 11Failedpods with reasonEvictedfrom ReplicaSetact-runner-5944dfdfb8, ten of them started 2026-10-30T08:26Z. The running runner isact-runner-fc597f6b5-vsvkl. So the warning comes from a leftover evicted (Failed) pod that Velero still tries to back up volumes for. Cleaning up the evicted pods is an operator action. - Gate: see the PR description for the toolbox
ci/gate.shrc and the skipped stages.
What I did NOT verify
- The CI image build (
.gitea/workflows/images.yaml) on this branch. It runs on push/PR and I have not seen its result while writing this. - An arm64 build. Only amd64 was built (
TARGETARCHdefaults to amd64). - Any mutating velero command (
backup create,restore,delete). None were run. - Why only
-69bvqof the 11 evicted act-runner pods shows up in the warning. A likely guess is that only that pod's volumes match the backup's pod-volume selection, but I did not check.