fix(ci): adapted CI workflows for the new vesion

[Andrey Kolkov (androndo)]

No description provided.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 86cbe771-b8de-40c5-ac7f-79a4c4416c98

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Timofei Larkin (lllamnyp)]

The release-engineering setup is well-built — GHCR over the dead Docker Hub path, cosign signing, the OCI Helm chart, and a real PR-gating install smoke test. Two defects in the publish path before merge, plus one direction change you can take as a follow-up.

Blocking

1. Multi-arch image build will fail the arm64 leg

docker-publish.yml:71 builds linux/amd64,linux/arm64, but the job sets up only buildx — no setup-qemu-action — and builds the plain Dockerfile, whose builder stage is FROM golang:1.25.10 AS builder (Dockerfile:2), not pinned to $BUILDPLATFORM. So buildx instantiates the builder as the target arch: the arm64 leg runs go build as an emulated arm64 process, and with no QEMU registered it dies at the first RUN with exec format error. The arm64 image never publishes and cosign never runs.

The Dockerfile is already cross-compile-ready (CGO_ENABLED=0 GOARCH=${TARGETARCH}, Dockerfile:25) — it just needs the builder to run natively. Fix: FROM --platform=$BUILDPLATFORM golang:1.25.10 AS builder. Then Go cross-compiles on the amd64 runner — no emulation, no QEMU, faster. (This is exactly what make docker-buildx already injects into Dockerfile.cross; the plain Dockerfile is the single-arch host variant and shouldn't be fed to multi-arch buildx as-is.)

Test: release-smoke.sh can't catch this — it does a single host-arch docker build. Add a build-only multi-arch assertion on the existing trigger (Dockerfile/docker-publish.yml already in scope): docker buildx build --platform linux/amd64,linux/arm64 -t etcd-operator:buildtest . (no --push/--load). Red on arm64 today, green after the fix.

2. The user-facing CLIs aren't released — for any OS/arch

release-assets.yml uploads only install manifests. etcd-migrate and kubectl-etcd are never built or attached. These are client-side tools that run on operators' workstations (linux & darwin, amd64 & arm64) — exactly where multi-arch/multi-OS matters — yet users get nothing prebuilt and must make from source. For a kubectl plugin that's a poor distribution story, and etcd-migrate is reached for once, under migration pressure — "build it yourself first" is friction at the worst moment.

Both are CGO-off static binaries, so cross-compiling them on the amd64 runner is trivial (no emulation — the right way). Fix: add a GOOS/GOARCH matrix (linux/{amd64,arm64}, darwin/{amd64,arm64}) to release-assets.yml building each CLI and uploading via the same upload-release-action. A per-target go build in CI is the test.

Non-blocking — follow-up: make generation Helm-first, retire kustomize

Not required for this PR — fine as a fast-follow. The direction I'd like: generation targets the chart directly and the kustomize flow goes away, since there's little value keeping both. Concretely:

• CRDs straight into the chart. Point controller-gen at the chart (output:crd:artifacts:config=charts/etcd-operator/crds), drop config/crd/bases and the helm-sync copy step. Repoint crdBasesDir() in api/v1alpha2/validation_envtest_test.go:57/80 at the new location, or envtest breaks. Bonus: the existing codegen-drift CI gate (make manifests + git diff) then covers the chart CRDs for free — closing the unguarded chart-CRD-drift gap.
• RBAC single-sourced into the chart. Today templates/rbac.yaml hand-mirrors the generated config/rbac/role.yaml (its own comment admits the smoke test is the only guard). controller-gen emits static YAML, so the bridge is: generate the rules to a chart-vendored file (e.g. charts/etcd-operator/files/manager-role-rules.yaml) and have the templated ClusterRole pull them in ({{- .Files.Get … | nindent }}), keeping Helm's release-scoped name/labels while the rules are generated-once. Removes the second source of truth.
• Retire kustomize. install/deploy/undeploy → helm upgrade --install / helm uninstall (the chart already renders image == OPERATOR_IMAGE, so the kustomize image-replacement contract moves into the chart). build-dist-manifests → helm template piped through the existing yq split, so release-assets still ships plain CRDs/non-CRDs YAML for non-Helm users. Then delete config/default, config/manager, config/rbac, the config/crd overlay, and the kustomize tool dep (keep config/samples; fold config/prometheus's ServiceMonitor into the chart behind a metrics.serviceMonitor.enabled value).

One decision this forces: CRD upgrades. Helm's crds/ dir is install-only (helm upgrade won't touch it), whereas the kustomize/kubectl apply path did upgrade CRDs. If kustomize goes away, either move CRDs under templates/ with a crds.install/crds.keep toggle (templated, upgraded with the release — the cert-manager/prometheus-operator pattern) or document a manual CRD-apply step on upgrade. I'd lean to templated CRDs.