-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure that the result of CRD generation is always the same, if Java classes do not change #5508
Comments
Thanks for taking the time to report this issue @thomasdraebing 👍 We recently improved the situation by ordering properties( #5390 ), I think it's reasonable to also order the versions in a deterministic way. Would you be willing to submit a PR for this? cc. @metacosm |
This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions! |
The implementation uses a method from KubernetesVersionPriority to sort the versions by priority. The version with the highest priority comes first. This ensures deterministic generation und should fix fabric8io#5508.
) * Fix CRDGeneratorTest#checkGenerationIsDeterministic and extend to test v1beta1 CRDVersion * Add CRDGeneratorTest#checkGenerationMultipleVersionsOfCRDsIsDeterministic * Fix broken link in JavaDoc for KubernetesVersionFactory * Add sortByPriority for generic lists to KubernetesVersionPriority utility class * Add SortCustomResourceDefinitionVersionDecorator to CRDGenerator The implementation uses a method from KubernetesVersionPriority to sort the versions by priority. The version with the highest priority comes first. This ensures deterministic generation und should fix #5508. * Add changelog for #5508 * Add license headers to SortCustomResourceDefinitionDecorators * Add not-null check to KubernetesVersionPriority#sortByPriority * Add NPE tests to KubernetesVersionPriorityTest * Fix javadoc in KubernetesVersionPriority
Is your enhancement related to a problem? Please describe
In some situations, notably if multiple versions of a CustomResource exist, the result of CRD generation differs from run to run in the order in which the versions are added to the list. While this doesn't change the behaviour of Kubernetes, since the version order does not matter, it causes unnecessary changes if checked into git or applied to the cluster.
Describe the solution you'd like
There should be an ordered List of CR versions in the generated CRD either from oldest to newest or newest to oldest version.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: