feat: migrate to upstream flux controllers

[drey]

Summary

Moves the module off the werf forks of flux and onto upstream fluxcd/helm-controller v1.6.4 and fluxcd/source-controller v1.9.5. The internal CustomResourceDefinitions are no longer hand-maintained copies: a small generator derives them from the upstream ones at pinned tags, and CI fails if the committed files drift. The proxy's rename table follows the upstream groups and identifiers, both module controllers build against the upstream API modules, both images are built from upstream, and the source image loses the nelm in its name along with the fork it was named after.

Branched from feat/ns-scoped-applications (#77), not from main.

Why

The forks exist to replace Helm with the nelm engine. Carrying them costs a rebase of two controllers against every upstream release, and the internal CRDs had to be edited by hand to match. Moving to upstream drops both costs and gives up nelm's behaviour deliberately — that is the goal of the change, not a side effect of it.

Key changes

Generator (tools/internalcrds). A new Go module that reads upstream's config/crd/bases and writes the internal definitions: group to {source,helm}.internal.operator-helm.deckhouse.io, every kind prefixed InternalNelmOperator, short names and categories dropped so the module cannot take hr, hc and the all category away from a real flux in the same cluster. Two guards fail the build rather than emit a half-renamed file: one rejects any leftover toolkit.fluxcd.io string in the output, the other rejects a kind the generator does not know, so a future flux version cannot silently introduce an unrenamed identity. task generate:internal-crds regenerates, task ci:generate:internal-crds verifies the committed files, and the lint workflow runs it.

Proxy (images/kube-api-rewriter/pkg/operatornelm). Only the left side of the rename table moves. Every stored identity — the internal group, the kind prefix, resource names, the annotation namespace, finalizer strings — is byte-identical to before, because each one names objects, finalizers and release secrets that already exist in every cluster running this module. The one deliberate exception is reconcile.fluxcd.io/resetAt, which never had a rule at all: the fork wrote reconcile.werf.io/resetAt straight through to the cluster. Neither controller reads or writes it, so it joins its two siblings in the internal namespace instead of freezing on the domain we are leaving.

Controllers (images/operator-helm-controller, images/chart-values-controller). Import paths swapped to fluxcd/helm-controller/api v1.6.4, fluxcd/source-controller/api v1.9.5, fluxcd/pkg/apis/meta and fluxcd/pkg/chartutil at the versions helm-controller itself pins. helm.sh/helm/v3 is gone from the code, the module files and the module graph: upstream's chartutil takes Helm v4 types, and carrying both majors would leave every later reader guessing which one is authoritative.

Build and chart. Both werf.inc.yaml files clone upstream at the pinned tags; images/nelm-source-controller/ became images/source-controller/, which renames the built image, because .werf/images.yaml derives the image name from the directory. The chart followed: the templates directory, four spellings of the name, two Helm template names, the ServiceAccount named in the ValidatingAdmissionPolicy allow-list, the e2e config, oss.yaml and build/components/versions.yml. A new task check-flux-tags, run from CI, fails if the tags in the werf files and build/components/versions.yml disagree.

Verification

task test:unit, task lint, task ci:generate:api and task ci:generate:internal-crds all exit 0; regenerating the internal CRDs from the pinned tags reproduces the committed files byte for byte. The chart renders and the Deployment, ServiceAccount, RBAC bindings and admission-policy allow-list all resolve to one name. Every flag the deployments pass exists in upstream's main.go at these tags, and upstream's own RBAC requirements are covered by the ClusterRole.

Not verified here: werf build has not run (no werf, no registry), and neither has e2e against a cluster.

Review focus / risks

• The engine swap only shows on a cluster. Releases written by nelm must be read by helm-controller on Helm 4, with drift detection enabled on every release. The first pass after the upgrade may see every field as drift and issue an upgrade per release. This is the accepted headline risk of the change and the e2e run on an upgraded cluster is the only place it surfaces.
• Origin labels on chart resources. helm-controller labels every rendered resource with <group>/name and <group>/namespace. The proxy rewrites request bodies only for the resource types on its own list, so a chart's Ingress, CronJob, HorizontalPodAutoscaler or arbitrary CRD instance keeps the label verbatim. The mechanism is not new — the fork left helm.werf.io/name on exactly the same resources — but the leaked string is now a genuine flux identity, which in a cluster running a real flux reads as someone else's origin label. Widening the proxy's list means editing shared vendored code, which this change does not touch. The first apply of each release after the upgrade replaces the old labels, since they come from the release manifest.
• The upgrade window on the renamed Service. --storage-adv-addr is built from the Service name, so artifact URLs already recorded in HelmChart.status.artifact.url point at a Service that no longer exists until source-controller re-reconciles at startup. Its storage is an emptyDir, so a fresh pod republishes everything. The ServiceAccount is likewise replaced rather than kept alongside the old one, with no transitional period.
• SOURCE_REPO. The images clone through it and it defaults to GitHub. If the build pipeline points it at a mirror, that mirror must carry fluxcd/helm-controller and fluxcd/source-controller at those paths. There is no other SOURCE_REPO clone in the repository to compare against.
• Version and dependency movement. The internal CRDs now serve one version per kind instead of two, because upstream removed the beta versions; the surviving version is the one that was already the storage version in this module since its first commit, so nothing stored is lost. The dependency upgrade carries controller-runtime 0.23.1 → 0.24.1 and the k8s.io/* set to 0.36.x; none of the behaviour that changed there is used by this module. go mod tidy was deliberately not run, so both go.sum files still carry fork checksums.

🤖 Generated with Claude Code