-
Notifications
You must be signed in to change notification settings - Fork 30
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
Research on tests for API Changes options #1247
Comments
Idea 1Use the generated OpenAPISpecification (OAS) v3 schema and compare old vs new version for differences in a GH Action. TL;DR: the only viable option seems to be option 3
1.
|
Idea 2Create a test that is looping over all fields of the respective Go structs. The test fails if one struct contains a field that the other doesn't, and if the types of the fields (only checking name) do not match. For known deviations, exceptions are added. To prepare for future evolution of currently shared types (e.g., A PoC for this can be found here: https://github.com/kyma-project/lifecycle-manager/pull/1490/files + part of the existing unit testing pipeline (fast feedback)
- cannot detect changes originating from generator annotations (e.g., json names, enum values, k-8s map extensions, ...) |
Closing as we agreed to implement Idea 1 Option 3 as a first step in #1492. If we find that it makes difficulties we will adapt the approach. |
Description
Since we can have multiple API versions supported (now we have v1beta1 and v1beta2), we need to investigate a way to add tests to validate that any changes/fields added to an API version get added to the other version as well.
Reasons
Since we can have multiple API versions supported, it can likely happen that we only add a field to the new API version forgetting about the old ones, and this can introduce issues in the Lifecycle Manager
Acceptance Criteria
Feature Testing
No response
Testing approach
No response
Attachments
No response
The text was updated successfully, but these errors were encountered: