fix: set correct groupName tag for packages.operators.coreos.com

[manusa]

Description of the change:

Seems like the groupName tag is not correct for the packagemanifest_types located in both pkg/package-server/api/operators and pkg/package-server/api/operators/v1.

These changes address the problem.

Both register.go files do point to the correct package name though.

• operator-lifecycle-manager/pkg/package-server/apis/operators/register.go

  Line 9 in 75d70e6

  Group = "packages.operators.coreos.com"

• operator-lifecycle-manager/pkg/package-server/apis/operators/v1/register.go

  Line 12 in 75d70e6

  Group = "packages." + operators.GroupName

Motivation for the change:

Correct generation of an OpenAPI client.

Architectural changes:

n/a

Testing remarks:

n/a

Reviewer Checklist

• Implementation matches the proposed design, or proposal is updated to match implementation
• Sufficient unit test coverage
• Sufficient end-to-end test coverage
• Bug fixes are accompanied by regression test(s)
• e2e tests and flake fixes are accompanied evidence of flake testing, e.g. executing the test 100(0) times
• tech debt/todo is accompanied by issue link(s) in comments in the surrounding code
• Tests are comprehensible, e.g. Ginkgo DSL is being used appropriately
• Docs updated or added to /doc
• Commit messages sensible and descriptive
• Tests marked as [FLAKE] are truly flaky and have an issue
• Code is properly formatted

[openshift-ci]

Hi @manusa. Thanks for your PR.

I'm waiting for a operator-framework 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.

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.

[manusa]

I've added a subsequent commit (b4e0390) to update the generated code according to the updated groupName tag.

However, I'm not sure if this implies certain breaking changes.

[perdasilva]

/ok-to-test

[perdasilva]

@manusa thanks for this - I'm currently chasing someone more knowledgeable than myself to try to understand how this happened in the first place to see if there was any method behind the madness and to get a bit more certainty that the change shouldn't break anything. Please bear with me ^^