Skip to content

Migrate code generation to kube_codegen.sh, bump to gengo-builder release-1.34 - #672

Merged
tamalsaha merged 1 commit into
masterfrom
kube-codegen-migration
Sep 2, 2026
Merged

Migrate code generation to kube_codegen.sh, bump to gengo-builder release-1.34#672
tamalsaha merged 1 commit into
masterfrom
kube-codegen-migration

Conversation

@tamalsaha

Copy link
Copy Markdown
Contributor

Summary

Mirrors the same migration already done for kubedb.dev/apimachinery, kubevault.dev/apimachinery, voyagermesh.dev/apimachinery and kubeops.dev/petset: replaces the old generate-groups.sh based clientset target with update-codegen.sh, a generic script bundled into CODE_GENERATOR_IMAGE (see gengo-builder's scripts/update-codegen.sh for the full env-var interface).

  • GENERATORS is scoped to deepcopy,client only (no lister/informer), matching what the old generate-groups.sh call here actually generated.
  • apis/shared has no client of its own (it's not part of API_GROUPS) but still needs deepcopy, hence EXTRA_DEEPCOPY_PKGS.
  • openapi-shared/openapi-% are updated for the new openapi-gen CLI (positional packages + --output-dir/--output-pkg/--output-file instead of --input-dirs/--output-package); their input list also drops go.bytebuilders.dev/catalog/api/v1alpha1, an unresolvable reference (not in go.mod/vendor, not imported anywhere under apis/ -- only an unrelated cmd/import-crds tool references a same-named but different package) that the old openapi-gen silently tolerated but the new one hard-fails on.

The interesting part

12 +genclient types across editor/identity/meta (EditorModel, AuditTokenRequest, InboxTokenRequest, ChartPresetQuery, ClusterStatus, Render, RenderDashboard, RenderMenu, RenderRawGraph, ResourceGraph, ResourceManifests, ResourceQuery) are request/response payloads with no metav1.ObjectMeta -- the new gentype-based client-gen would otherwise require adding it (or dropping +genclient) for all 12, the same problem kubedb.dev/apimachinery's DatabaseSummary hit (kubedb/apimachinery#1889).

Instead of touching any of the 12 types, this bumps kmodules.xyz/client-go to pick up its new create-only gentype.Client[T runtime.Object] (kmodules/client-go#646) and a matching kmodules/code-generator client-gen patch that detects this exact shape (+genclient:onlyVerbs=create with no ObjectMeta) and builds the client on it instead of k8s.io/client-go/gentype's Client[T], which requires metav1.Object. So apis/ needed zero changes for any of the 12 types.

Verification

Ran locally against the real ghcr.io/appscode/gengo:release-1.34 image: check-license, lint, build, and a full make gen (update-codegen, manifests, openapi) -- zero apis/ diff, and the only crds/ diff is the newer controller-gen (ac-0.19.0) dropping the null creationTimestamp field CRD YAML used to carry.

make unit-tests passes except hub.TestRegister, which needs a live cluster (KUBERNETES_MASTER) that this repo's CI provisions via kind but wasn't available in my local environment to verify -- not something this migration touches, and CI's k8s job will exercise it for real.

kodiakhq[bot]
kodiakhq Bot previously approved these changes Sep 2, 2026
kodiakhq[bot]
kodiakhq Bot previously approved these changes Sep 2, 2026
…ease-1.34

Mirrors the same migration already done for kubedb.dev/apimachinery,
kubevault.dev/apimachinery, voyagermesh.dev/apimachinery and
kubeops.dev/petset: replaces the old generate-groups.sh based
clientset target with update-codegen.sh, a generic script bundled into
CODE_GENERATOR_IMAGE (see appscodelabs/gengo-builder's
scripts/update-codegen.sh for the full env-var interface).

GENERATORS is scoped to deepcopy+client only (no lister/informer),
matching what the old generate-groups.sh call here actually generated.
apis/shared has no client of its own (it's not part of API_GROUPS) but
still needs deepcopy, hence EXTRA_DEEPCOPY_PKGS. openapi-shared/
openapi-% are updated for the new openapi-gen CLI (positional packages
+ --output-dir/--output-pkg/--output-file instead of --input-dirs/
--output-package); their --input-dirs list also drops
go.bytebuilders.dev/catalog/api/v1alpha1, an unresolvable reference (no
such package is in go.mod/vendor, or imported anywhere under apis/ --
only an unrelated cmd/import-crds tool references a same-named but
different package) that the old openapi-gen silently tolerated but the
new one hard-fails on.

12 +genclient types across editor/identity/meta (EditorModel,
AuditTokenRequest, InboxTokenRequest, ChartPresetQuery, ClusterStatus,
Render, RenderDashboard, RenderMenu, RenderRawGraph, ResourceGraph,
ResourceManifests, ResourceQuery) are request/response payloads with no
metav1.ObjectMeta -- the new gentype-based client-gen would otherwise
require adding it (or dropping +genclient) for all 12, same as
kubedb.dev/apimachinery's DatabaseSummary needed. Instead, this bumps
kmodules.xyz/client-go to pick up its new create-only gentype.Client[T
runtime.Object] (kmodules/client-go#646) and the matching
kmodules/code-generator client-gen patch that detects this shape
(+genclient:onlyVerbs=create with no ObjectMeta) and builds the client
on it instead of k8s.io/client-go/gentype's Client[T], which requires
metav1.Object -- so none of apis/ needed any changes at all, for any of
the 12 types.

Verified with make check-license, lint, build, and a full make gen
(update-codegen, manifests, openapi) against the real gengo-builder
release-1.34 image -- zero apis/ diff, and the only crds/ diff is the
newer controller-gen (ac-0.19.0, up from whatever this repo's
release-1.32-era CODE_GENERATOR_IMAGE shipped) dropping the null
creationTimestamp field CRD YAML used to carry. make unit-tests passes
except hub.TestRegister, which needs a live cluster (KUBERNETES_MASTER)
that this repo's CI provisions via kind but wasn't available to verify
locally -- not something this migration touches.

Signed-off-by: Tamal Saha <tamal@appscode.com>
@tamalsaha
tamalsaha merged commit d79fb62 into master Sep 2, 2026
8 checks passed
@tamalsaha
tamalsaha deleted the kube-codegen-migration branch September 2, 2026 19:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant