question: how to check if there are breaking changes from the command line? about openapi-diff

[quen2404]

Available in release 1.2.0

[quen2404]

If i had this option --fail-on-incompatible we will be able to do it:

I guess the use case for checking for checking only for backward compatibility is:

There is a diff but it is backward compatible => OK (Return 0)
There is a diff that is not backward compatible => NOK (Return 1)

I'm suggesting this algorithm to improve current behavior in cli mode ;

What you are suggesting is:

No diff: Return code 0
Diff and not backward compatible: Return code 1
Diff that is backward compatible: Return code 2

[quen2404]

$ openapi-diff <old> <new> --state
<state>

With <state> in : no_changes,imcompatible,compatible (thanks for this proposition @itsjavi).
What do you think ?

[itsjavi]

it sounds good 👍

[jmini]

The main method provided by the project com.qdesrame.openapi.diff.Main focuses on creating report.
As you can see in the code Line 129, the return status check if there is a diff or not.

System.exit(result.isDiff() ? 1 : 0);

The class ChangedOpenApi (result is an instance of it) provides also a isDiffBackwardCompatible() method.

For the moment, you will need to write your own Main class that creates a ChangedOpenApi instance for the two spec you provide as input. Then you can call isDiffBackwardCompatible() and do a System.exit call.
(If you need more details, just continue the discussion).

---

I am not really an expert on CLI tools written in Java, but maybe an option could be added “return code” or "exit check" with 2 possible values:

• diff current and default behaviour
• backward

This way the use-case described in this question could be addressed for CLI users.
@quen2404: what do you think?

[itsjavi]

Thank you for your detailed response

I think it would be enough to have an option like --fail-on-incompatible or similar.

[quen2404]

Hi,
@jmini i can update main method to return a new code if contract changed with backward compatibility (maybe with code 2 ?).
@itsjavi I can add a new option if you want that the tool failed when it broke the compatibility.

[jmini]

@quen2404 that is what I mean with "I am not familiar with CLI tools"... I have no input on what is the most appropriate.

I guess the use case for checking for checking only for backward compatibility is:

• There is a diff but it is backward compatible => OK
• There is a diff that is not backward compatible => NOK

What you are suggesting is:

• No diff: Return code 0
• Diff and not backward compatible: Return code 1
• Diff that is backward compatible: Return code 2

This is not exactly the same. Maybe it can be used. @itsjavi what is your opinion?

PS: I am using the lib at Java level (integrated in some Unit Tests).

[itsjavi]

No diff: Return code 0
Diff and not backward compatible: Return code 1
Diff that is backward compatible: Return code 2

Note that program exit codes different than 0 are commonly used for reporting errors, so the return code 2 for indicating a "successful" state would be inappropriate in this case.

I like the first solution you suggested:

There is a diff but it is backward compatible => OK (exit code 0)
There is a diff that is not backward compatible => NOK (exit code 1)

If you still want to support a more variety of results/states I'd suggest to print a keyword instead, indicating the state, for example:

• No diff prints: no_changes
• Diff and not backward compatible: incompatible
• Diff that is backward compatible: compatible

But I am not sure how that will work with the verbosity options, since it won't be the only thing printed.

[quen2404]

Done in PR #38

[itsjavi]

That's awesome! thank you =)