Info - level changes #541
Replies: 3 comments 1 reply
-
Hi @dublintech Reuven |
Beta Was this translation helpful? Give feedback.
-
The best way to understand the checks and their levels is by running
The commands above will return a non-zero error code if any change is found with a higher or equals level. Change levels are ordered: I hope this provides enough detail without having to look at the "breaking changes examples" which, as you correctly pointed out, is a little confusing (I hope to correct it at some point). |
Beta Was this translation helpful? Give feedback.
-
Thanks for getting @reuvenharrison So to take an example, some of the rules in "INFO" section will log at info. Can see this in the source code and tests. So if you take adding a new tag You can test checks for info and source code also info. However, other one's such as: changing request property format are in the "INFO" section but then when you look at test and source, I am little confused. There's two tests, looking to cover format changes that are breaking and format changes that are non-breaking:
So, what I am curious about is what format changes you consider breaking and what you consider not breaking. Then when look at the tests: TestRequestBodyFormatChangedCheck, it looks like it is using the same YAML for the type test ../data/checker/request_property_type_changed_base.yaml" Base File https://github.com/Tufin/oasdiff/blob/main/data/checker/request_property_type_changed_base.yaml This changes the "type" of the age field from int to string. So if I understand that correctly, that is going to check the "type" but not the "format" Wondering is it possible to see what "Format" only changes you consider to be breaking and what you consider to be non-breaking? Many thanks |
Beta Was this translation helpful? Give feedback.
-
Thanks for a super super tool. I am just wondering abiout this section: https://github.com/Tufin/oasdiff/blob/main/BREAKING-CHANGES-EXAMPLES.md . There is an extensive list of "breaking changes" and an extensive list of "non breaking changes". After that there is a list of "info-level" changes.
I am curious about the "info level" . Is it not possible to designate them as breaking or non-breaking?
Some of them sound like depending on how client code or code generation tooling is written e.g. format change, will depend on if you have a break or not. This is messy because then trivial things could end being designated as a breaking change and we could write back to treating what are meant to be RESTful interfaces as like SOAP WSDLs which generate tightly coupled code.
Would be really interested in views on this.
And thanks again for a great tool
Beta Was this translation helpful? Give feedback.
All reactions