Ability to supply custom rules

[venkow]

Hey, I am using the embedded-swagger-brake, so was wondering if might be a good idea to also support supplying custom rules.

[galovics]

Hi @venkow, right. Actually, it's already possible just by registering a custom BreakingChangeRule as a Spring bean. Depending on how you actually trigger the break check, you could build up a custom ApplicationContext, like right here: https://github.com/redskap/swagger-brake/blob/master/swagger-brake/src/main/java/io/redskap/swagger/brake/runner/Starter.java#L44

Although I think this could solve the issue, probably it's not the most convenient way to do so.

Are you looking for an extension like this for the Gradle plugin or for the core library?

[venkow]

@galovics Was thinking more for the Gradle plugin. Something on the lines of how CheckerOptions are passed to check(OpenAPI, OpenAPI, CheckerOptions) from this example: https://redskap.github.io/swagger-brake/devguide/#embedding-swagger-brake.

But that might be coming a bit short sighted from my end, as the above entry point is the only one I have used so far. You will have a better idea, and further more, if it is something that we can do as an external contribution, we can look into that as well :) .

[galovics]

@venkow Sure. By the way what's the particular rule you're missing?

[dvenkov]

Well, had a few. Some of them are:

• Duplicate OperationIds
• A changed Tag rule
• Change of the Components.Schema's objects (basically a change in the name of a model)

Not sure those are widely considered as swagger breaking changes, but for our use case, they are needed.

[galovics]

@dvenkov Got it. I can certainly create an extension point for the first 2.

Can you please give an example of the third one? If the model changes it should be considered as a breaking change. Maybe this is a specific use-case that's not implemented yet.

Thanks!

[venkow]

Hey, (I commented from my other github account above - dvenkov).

So just as an overview of the 3rd use case -> a model's name change impacts our use of swagger-codegen. Anyone using our client built with swagger-codegen will experience a breaking change if the model's name was updated. Maybe next week I can send examples for clarity on this one.