Fix config/crd/bases vs helm/crds list-marker mismatch (gofmt ordering)

[HansG89]

Problem

For any generated field whose Go doc comment contains a Markdown bullet list (e.g. an enum's valid-values doc), config/crd/bases/*.yaml and helm/crds/*.yaml permanently disagree on the list-marker style (* vs -) for identical description text. Regenerating a service controller always "flips" one of the two files relative to the other, which makes CI's verify-code-gen diff check impossible to satisfy.

Example live on aws-controllers-k8s/glue-controller main today (Job.spec.jobMode doc):

helm/crds/glue.services.k8s.aws_jobs.yaml:2815:                    - SCRIPT - The job was created using the Glue Studio script editor.
config/crd/bases/glue.services.k8s.aws_jobs.yaml:2815:                     * SCRIPT - The job was created using the Glue Studio script editor.

This is what's currently blocking aws-controllers-k8s/glue-controller#16 in CI (glue-verify-code-gen)

Root cause

Both YAML targets are produced by separate controller-gen crd invocations reading from the same generated apis/<version> Go source tree, within a single make build-controller run:

1. scripts/build-controller.sh: ack-generate apis writes the Go doc comments (the HTML <li> renderer in pkg/api/docstring.go always emits * -style markers), then controller-gen crd runs against that raw, not-yet-gofmt'd source to produce config/crd/bases/*.yaml. gofmt -w only runs later, at the very end of this script.
2. scripts/build-controller-release.sh (run immediately after, by the same make build-controller target): its own controller-gen crd call runs against the already-gofmt'd source (persisted from step 1's end-of-script gofmt -w) to produce helm/crds/*.yaml.

Go's doc-comment reformatter rewrites *-style Markdown list markers in doc comments to -. Because the two controller-gen crd calls straddle that rewrite, they capture the same doc comment on opposite sides of it, and the two output targets disagree forever after, independent of anything the service-controller author does.

Confirmed via local repro (isolated gofmt runs reproducing the rewrite, plus a live make build-controller SERVICE=glue run before/after this fix).

Fix

Move the doc-comment-normalizing gofmt -w in scripts/build-controller.sh to run immediately after ack-generate apis completes, before either controller-gen crd invocation reads the source, instead of only at the end of the script (after the first controller-gen crd call has already run). The existing end-of-script full-tree gofmt -w / goimports -w is left in place for the rest of the generated code (controller, deepcopy, etc.); running gofmt twice on already-formatted source is a no-op.

Verification

Ran make build-controller SERVICE=glue twice back-to-back against a clean glue-controller checkout:

• config/crd/bases/glue.services.k8s.aws_jobs.yaml and helm/crds/glue.services.k8s.aws_jobs.yaml are now byte-identical (md5sum match) for the jobMode field and the rest of the schema.
• Second run produces an identical diff to the first (idempotent, no further drift).

Diff is scoped to generated CRD YAML plus normal gofmt'd doc-comment text in apis/*/types.go; no template, docstring.go, or schema-generation logic changes needed.

cc @michaelhtm

[ack-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: HansG89
Once this PR has been reviewed and has the lgtm label, please assign a-hilaly for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ack-prow]

Hi @HansG89. Thanks for your PR.

I'm waiting for a aws-controllers-k8s member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.