Azure / openapi-diff

Command line tool to detect breaking changes between two openapi specifications
MIT License
266 stars 37 forks source link

Is it possible to add custom rules? #240

Open rao-anant opened 2 years ago

rao-anant commented 2 years ago

Depending on the usage, we might want to add our rules, or modify existing rules by changing the type etc. Is it possible to do with openapi-diff? Thanks!

jianyexi commented 2 years ago

yes, you can create an issue for your new rule, we need to evaluate it

rao-anant commented 2 years ago

Thank you very much, Jianye!!!What if we want to add them to our company to use internally? Is it possible? BTW, is the code in OpenApiDiff.dll engine (not the node-based oad wrapper) open source? Thanks again!!Anant Rao

Sent from Yahoo Mail on Android

On Tue, Aug 30, 2022 at 10:18 PM, @.***> wrote:

yes, you can create an issue for your new rule, we need to evaluate it

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

rao-anant commented 2 years ago

--- Replying to all -- Thank you very much, Jianye!!!What if we want to add them to our company to use internally? Is it possible? BTW, is the code in OpenApiDiff.dll engine (not the node-based oad wrapper) open source? Thanks again!!Anant Rao

Sent from Yahoo Mail on Android

On Tue, Aug 30, 2022 at 10:18 PM, @.***> wrote:

yes, you can create an issue for your new rule, we need to evaluate it

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

jianyexi commented 2 years ago

I misunderstood, this repo is open source, so any new feature/idea is welcomed.
Currently the rule is distributed in the C# files, if you want to customize ruleset, to avoid breaking change, we may need to support something like rule configuration in the tool, do you have any proposal for it?

rao-anant commented 2 years ago

Hello Jianyexi,

Thanks for the suggestion. Here’s my proposal. Please let me know your feedback.

After processing each change/diff (between the two spec files), you’ll call a plugin developed by me against an interface specified by you.

The interface/plugin takes one input param, which is the context that you are currently printing in the output: • Id • Message • Old struct • New struct • Type • docUrl • mode

The plugin returns a structure containing: • A return code • A new context, possibly. Please read below.

Return code from the plugin:

0 This means my Rules Engine/policy agrees with the determination made by yours. No context is returned. You’ll just print the message as before - that is, message that you already have/prepared.

+1 This means your Rules engine found the change to be backward-Incompatible and mine finds it Compatible. No context is returned by me, and you will not print any message for this change. Basically, you’ll ignore this change as though it didn't exist.

-1 This means your Rules engine found the change to be backward-Compatible and mine finds it Incompatible. A new context is returned in this case and you’ll print this new context (instead of the one you have/prepared).

The context I return will have new values for the following fields and the rest of the fields will be copied from the context given in the input:

• Id (You can reserve codes >= 5000 for plug-in developers. As an example, I might return 5001) • Message – My customized message • Type • docUrl -> This could potentially point to my URL

Please let me know your thoughts. Thanks very much! Anant