From c6f1fe317e4450fbe25f07aa51eb078c10cd0e2e Mon Sep 17 00:00:00 2001 From: Niklas Ye Date: Tue, 1 Sep 2026 22:44:22 +0200 Subject: [PATCH] Correct the docs that said this repo has no publishing targets MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Both CLAUDE.md and README.md claimed there were deliberately no build or push targets because the workflow owned publishing. That stopped being true in 69fcc24, which moved publishing onto the Makefile so release.yaml could call it — the docs described the arrangement that change replaced. The claim was wrong in its reasoning too, not just out of date. It was written on the assumption that riksdata and rd-web duplicated their pipelines by having those targets. They never did: their workflows call make and always have, which is what makes a green gate locally and a green pipeline the same code instead of two descriptions of it. This repo was the exception, for the single day it had a Makefile that nothing called. Claude-Session: https://claude.ai/code/session_01S7R4gWTz5wh5xCY4nCSJjN --- CLAUDE.md | 13 ++++++++----- README.md | 15 +++++++++++---- 2 files changed, 19 insertions(+), 9 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 6c69290..171fd1b 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -24,9 +24,12 @@ Two things about this repo specifically: ## Checks -`make fmt lint test helm-lint` mirrors `.gitea/workflows/ci.yaml`, so a green gate here means -a green pipeline there. The one deliberate difference is `-race`, which CI does not run; see -the comment on the `test` target. +`make fmt lint test helm-lint` **is** what the pipeline runs — `ci.yaml` and `release.yaml` +call these targets rather than restating them, the way riksdata and rd-web do. A green gate +here and a green pipeline are the same code, not two descriptions of it. `test` adds `-race`, +which the workflows do not have to ask for since they call the target; see the comment on it +for why. -There are deliberately no `build`/`push`/`helm-push` targets — the workflow owns publishing, -and it builds multi-arch. Publishing happens by pushing a tag. +`make release` (build + push the multi-arch image, package + push the chart) is what +`release.yaml` invokes. Do not run it by hand — it refuses `VERSION=dev` for that reason, and +publishing happens by pushing a tag. diff --git a/README.md b/README.md index 013a08a..a2be216 100644 --- a/README.md +++ b/README.md @@ -695,10 +695,17 @@ different answers — chart 0.9.0 went out reading `appVersion: "latest"` that w publisher, triggered by the tag (`766f439`). The cost is that a chart-only change has no version of its own and rides the next app tag. -There is deliberately **no** `make build` / `make push`. The workflow builds -`linux/amd64,linux/arm64` through buildx; a local single-platform push would land on top of -the multi-arch tag and stay invisible, because the tag would still resolve — just not on -arm64. Publishing happens by pushing a tag. +Both workflows are thin drivers over the Makefile: `ci.yaml` runs `make fmt lint test` and +`make helm-lint`, `release.yaml` adds `make binaries`, `make push`, `make helm-package` and +`make helm-push`. That is deliberate — it is what makes a green local gate and a green +pipeline the same code rather than two descriptions of it, and it is how riksdata and rd-web +have always worked. + +`make push` builds and pushes in one step, unlike those two, because the image is +`linux/amd64,linux/arm64` and buildx cannot load a multi-platform result into the local image +store. `make build` stays single-platform and local-only. Both refuse `VERSION=dev`: +publishing is one command, so it is also one command to run by accident. Publishing happens +by pushing a tag. Two things the release process needs to know about this repo: