Add kubeconform and kube-linter to the base image #18

Merged

GuillaumeHemmen merged 1 commit from feat/base-kube-qa-tools into master

2026-07-24 06:41:25 +00:00

claude-bot commented

2026-07-23 16:07:41 +00:00

Member

What

Add kubeconform (v0.8.0) and kube-linter (v0.8.3) to the base stage, so all three published variants inherit them: ci (Forgejo pipelines), coder, and coder-xfce-vnc.

Why

Repos that lint/validate k8s manifests (searxng, forgejo, …) currently install these in every CI job via:

- uses: actions/setup-go@v6      # downloads the whole Go toolchain, every run
- run: go install …@latest       # fetches the module tree + COMPILES from source

That's a Go-toolchain download plus a from-source compile of each tool on every job — slow, unpinned, and network-fragile (it was hanging for minutes on this cluster). Baking pinned prebuilt binaries lets pipelines run kubeconform / kube-linter directly (seconds, reproducible, no runtime Go/proxy/GitHub dependency), and gives the coder/desktop workspaces the same tools for linting before a push.

Why `base` (not `ci`, not `update-k8s-tools.sh`)

base → one definition, inherited by every variant — matching the Firebase precedent ("in base so every variant ships it").
Baked, not runtime: unlike kubectl/helm/talosctl (cluster-version-coupled, fast-moving → update-k8s-tools.sh at runtime), these are dependency-free static binaries with a slow release cadence, and CI needs them present at job start — runtime install is the exact flakiness being removed.

Implementation

Same fetch idiom as the Firebase block (bounded curl retries, then assert-runs), placed right after it in base:

ARG KUBECONFORM_VERSION=0.8.0
ARG KUBE_LINTER_VERSION=0.8.3
RUN curl … kubeconform-linux-amd64.tar.gz | tar -xz -C /usr/local/bin kubeconform &&     curl … kube-linter-linux.tar.gz        | tar -xz -C /usr/local/bin kube-linter &&     chmod +x /usr/local/bin/kubeconform /usr/local/bin/kube-linter &&     kubeconform -v && kube-linter version

Bump the ARGs to upgrade.

Verification

base already provides curl + tar and sets SHELL … pipefail, so a failed curl | tar fails the build.
Ran the exact install commands (piped, under pipefail): both extract and report versions cleanly (v0.8.0, 0.8.3).

Follow-up (separate repo)

Once this is built and ci-latest carries the tools, the consuming workflows drop setup-go + go install and switch container.image to git.van-hemmen.com/actions/sindri:ci-latest. (I can open that on searxng.)

🤖 Generated with Claude Code

## What Add **kubeconform** (v0.8.0) and **kube-linter** (v0.8.3) to the **`base`** stage, so all three published variants inherit them: `ci` (Forgejo pipelines), `coder`, and `coder-xfce-vnc`. ## Why Repos that lint/validate k8s manifests (searxng, forgejo, …) currently install these in every CI job via: ```yaml - uses: actions/setup-go@v6 # downloads the whole Go toolchain, every run - run: go install …@latest # fetches the module tree + COMPILES from source ``` That's a Go-toolchain download **plus a from-source compile** of each tool on every job — slow, unpinned, and network-fragile (it was hanging for minutes on this cluster). Baking pinned prebuilt binaries lets pipelines run `kubeconform` / `kube-linter` directly (seconds, reproducible, no runtime Go/proxy/GitHub dependency), and gives the coder/desktop workspaces the same tools for linting before a push. ## Why `base` (not `ci`, not `update-k8s-tools.sh`) - **`base`** → one definition, inherited by every variant — matching the Firebase precedent ("in base so every variant ships it"). - **Baked, not runtime:** unlike `kubectl`/`helm`/`talosctl` (cluster-version-coupled, fast-moving → `update-k8s-tools.sh` at runtime), these are dependency-free static binaries with a slow release cadence, and CI needs them present at job start — runtime install is the exact flakiness being removed. ## Implementation Same fetch idiom as the Firebase block (bounded `curl` retries, then assert-runs), placed right after it in `base`: ```dockerfile ARG KUBECONFORM_VERSION=0.8.0 ARG KUBE_LINTER_VERSION=0.8.3 RUN curl … kubeconform-linux-amd64.tar.gz | tar -xz -C /usr/local/bin kubeconform && curl … kube-linter-linux.tar.gz | tar -xz -C /usr/local/bin kube-linter && chmod +x /usr/local/bin/kubeconform /usr/local/bin/kube-linter && kubeconform -v && kube-linter version ``` Bump the ARGs to upgrade. ## Verification - `base` already provides `curl` + `tar` and sets `SHELL … pipefail`, so a failed `curl | tar` fails the build. - Ran the **exact** install commands (piped, under `pipefail`): both extract and report versions cleanly (`v0.8.0`, `0.8.3`). ## Follow-up (separate repo) Once this is built and `ci-latest` carries the tools, the consuming workflows drop `setup-go` + `go install` and switch `container.image` to `git.van-hemmen.com/actions/sindri:ci-latest`. (I can open that on searxng.) 🤖 Generated with [Claude Code](https://claude.com/claude-code)

claude-bot added 1 commit

2026-07-23 16:07:41 +00:00

Add kubeconform and kube-linter to the base image

/ docker-dev-ci (push) Successful in 3m44s

Details

/ docker-dev-coder (push) Successful in 8m21s

Details

/ docker-dev-coder-xfce-vnc (push) Failing after 8m49s

Details

5d0edc362f

CI pipelines validated/linted Kubernetes manifests by installing these via a
per-job `actions/setup-go` + `go install …@latest` — a Go-toolchain download
plus a from-source compile of each tool on every run, slow and network-fragile.

Bake them as pinned prebuilt release binaries in the shared base stage instead,
so every variant ships them: the ci image runs them directly in Forgejo
pipelines, and the coder/desktop workspaces can lint manifests before pushing.
Same fetch idiom (bounded retries + assert-runs) as the Firebase block; placed
in base rather than update-k8s-tools.sh because they are dependency-free static
binaries with no cluster-version coupling and CI needs them present at job start.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>