+operator-sdk:csv:customresourcedefinitions:order does not change order in bundle

[mateusoliveira43]

Bug Report

What did you do?

Created new structure with operator-sdk version v1.34.2. I ran the following commands:

mkdir 1_34_2
cd 1_34_2
operator-sdk init --project-name=oadp-operator --repo=github.com/openshift/oadp-operator --domain=openshift.io
# manually changed CONTROLLER_TOOLS_VERSION to v0.14.0 in Makefile because I am using go1.22.3 
operator-sdk create api --group oadp --version v1alpha1 --kind DataProtectionApplication --resource --controller
operator-sdk create api --group oadp --version v1alpha1 --kind CloudStorage --resource --controller
make bundle
# fill inputs with "test"

Then checked that in 1_34_2/config/manifests/bases/oadp-operator.clusterserviceversion.yaml and 1_34_2/bundle/manifests/oadp-operator.clusterserviceversion.yaml files, CloudStorage appears first then DataProtectionApplication (sorted alphabetically by default?) in spec.customresourcedefinitions.owned list.

Then, I manually added // +operator-sdk:csv:customresourcedefinitions:order=1 in 1_34_2/api/v1alpha1/dataprotectionapplication_types.go and ran make bunble again. In 1_34_2/config/manifests/bases/oadp-operator.clusterserviceversion.yaml the order changes, and DataProtectionApplication appears first, but not in 1_34_2/bundle/manifests/oadp-operator.clusterserviceversion.yaml.

What did you expect to see?

CRDs appearing in the order I desire in bundle CSV file.

What did you see instead? Under which circumstances?

CRDs appearing sorted alphabetically in bundle CSV file.

Environment

Operator type:

/language go

Kubernetes cluster type:

Not releated

$ operator-sdk version

operator-sdk version: "v1.34.2", commit: "81dd3cb24b8744de03d312c1ba23bfc617044005", kubernetes version: "1.28.0", go version: "go1.21.10", GOOS: "linux", GOARCH: "amd64"

$ go version (if language is Go)

go version go1.22.3 linux/amd64

$ kubectl version

Not related

Possible Solution

Not at the moment. (Manual workaround is changing order after running make bundle)

Additional context

This is important in my opinion, because UIs (like https://operatorhub.io/ and OpenShift) use the order the CRD appear in spec.customresourcedefinitions.owned list to render them. This way, developers can use the order to show priority of CRDs to users.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[mateusoliveira43]

/lifecycle frozen