vscode-swagger-diff ability to integrate with CI tool Jenkins or output in command line

[leowestx]

Hi there,

I was looking at this plugin and it is fantastic but I am just wondering if there is a way I can integrate this as part of the CI tool Jenkins in order to automate this process of creating release notes. Something like once a build is done, it will automate the process of comparing files and making release notes? Even if there is an option to generate the output into VS code CLI at least it would be great. Kindly let me know if any ideas to do this. Thank you

[psrabhishek]

Hi @leowestx ,

I am glad to hear you liked the tool and found it useful.

I understand what you mean by adding it to a CI tool to automate build notes. I am internally using a node package in the VSCode plug-in which is written in TypeScript.

You might not necessarily need to use the same plugin, instead you can come use a python, java or even a bash script to use such a library to get the swagger-diff and parse/process it the way you desire.

For example, I have written one python script for the organization I work, to get the diff for any selected Module (swagger file) between any two release versions, using the open-source library: https://github.com/Sayi/swagger-diff with HTML as output.

Similarly you can use any swagger-diff library which will give you more flexibility for your use case.

I am happy to help you if you can elaborate a bit more on your requirement. (like how do you want to pass the file path in input, how to determine which version of file you want to compare it with, what format of output you would want, etc)

[leowestx]

Hello,

Thank you so much for your quick reply. I am sorry is it okay if you can elaborate a bit more on what you meant here “ You might not necessarily need to use the same plugin, instead you can come use a python, java or even a bash script to use such a library to get the swagger-diff and parse/process it the way you desire.”

And in terms of what I am thinking to do for automate process - is that I have a Java+gradle project and maybe I am planning to add some task in build.gradle or a plug-in of a diff tool e.g) sayi/swagger-diff as it allows gradle plugin. Then each time code is committed and as part of Jenkins pull request check, I am planning to compare files between the latest builds maybe and generate the differences as a table format or html file anything as long as it’s fairly accurate and valuable information that can be used for release notes.

This is just a thought process, didn’t really plan or test out but I came across your plugin and it is really helpful and wanting to implement with Jenkins somehow because tools like sayi/swagger-diff isn’t capturing all the differences accurately but your plug in is literally what I want to integrate.

On Sat, 16 Apr 2022 at 12:03 AM, psrabhishek

@.***> wrote:

Hi @leowestx https://github.com/leowestx ,

I am glad to hear you liked the tool and found it useful.

I understand what you mean by adding it to a CI tool to automate build notes. I am internally using a node package in the VSCode plug-in which is written in TypeScript.

You might not necessarily need to use the same plugin, instead you can come use a python, java or even a bash script to use such a library to get the swagger-diff and parse/process it the way you desire.

For example, I have written one python script for the organization I work, to get the diff for any selected Module (swagger file) between any two release versions, using the open-source library: https://github.com/Sayi/swagger-diff with HTML as output.

Similarly you can use any swagger-diff library which will give you more flexibility for your use case.

I am happy to help you if you can elaborate a bit more on your requirement. (like how do you want to pass the file path in input, how to determine which version of file you want to compare it with, what format of output you would want, etc)

— Reply to this email directly, view it on GitHub https://github.com/psrabhishek/vscode-swagger-diff/issues/1#issuecomment-1100064893, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYXRIT57MBXIEDEEHLHNNB3VFFLHNANCNFSM5TQINNZA . You are receiving this because you were mentioned.Message ID: @.***>

[psrabhishek]

Hello,

What I meant by

“ You might not necessarily need to use the same plugin, instead you can come use a python, java or even a bash script to use such a library to get the swagger-diff and parse/process it the way you desire.”

Is that your are not just limited to my VS Code Plugin, you can use any other available libraries and use any custom script to do custom processing and get desired output.

Since you prefer the output coming from my plugin, you can use https://github.com/zallek/swagger-diff#cli to get the same results, but in a non-html format. And you would also need to figure out a way to give the old and new files as input, which can be generated using git commands.

If you want the output to be html format only like generated by my plugin, I will try to come up with a node module to get a similar HTML output, which can be used in similar fashion as mentioned in https://github.com/zallek/swagger-diff#cli but can yield a HTML file as output.

Hope that works out for you to integrate into your build gradle.

[leowestx]

Hello,

Thank you so much for your well defined reply. It makes a lot of sense. Sorry I have few questions but not sure if you are able to answer. I am still in the analysis/requirement phase but just wondering if

1) Any information that you can share with me about how to integrate Sayi/swagger-diff with CI

2) When we do a build run automatically will it generate swagger.json file?

Thank you

On Sun, 17 Apr 2022 at 3:15 AM, psrabhishek @.***> wrote:

Hello,

What I meant by

“ You might not necessarily need to use the same plugin, instead you can come use a python, java or even a bash script to use such a library to get the swagger-diff and parse/process it the way you desire.”

Is that your are not just limited to my VS Code Plugin, you can use any other available libraries and use any custom script to do custom processing and get desired output.

Since you prefer the output coming from my plugin, you can use https://github.com/zallek/swagger-diff#cli to get the same results, but in a non-html format. And you would also need to figure out a way to give the old and new files as input, which can be generated using git commands.

If you want the output to be html format only like generated by my plugin, I will try to come up with a node module to get a similar HTML output, which can be used in similar fashion as mentioned in https://github.com/zallek/swagger-diff#cli but can yield a HTML file as output.

Hope that works out for you to integrate into your build gradle.

— Reply to this email directly, view it on GitHub https://github.com/psrabhishek/vscode-swagger-diff/issues/1#issuecomment-1100686715, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYXRIT2UPRD7KQVU2WBB4P3VFLKSDANCNFSM5TQINNZA . You are receiving this because you were mentioned.Message ID: @.***>

[psrabhishek]

Hello,

Before I can answer #1, I want to ask about your #2.

There are different approaches for developing webservice and the specification provided to consumers.

1. Top-Down : first we define the specs(swagger, openAPI, XML schema, etc), it could be hand-typed, where the developer/product owner will define the spec and development is done abiding to the spec defined. we can check-in or commit these specs in our git repo if needed.

2. Bottom-UP: We develop our webservices first, and generate the spec (swagger, openAPI, XML schema, etc) from our developed code. In this case the spec might not be checked-in into git repo and could be generated at build time.

No matter the approach we need to have the spec file to with the consumers of our webservices.

So, to answer your #2, you should be the one knowing about the swagger.json being checked-in or generated in case of your product/application.

I will answer you other question once you get clarity on this. Since we need 2 inputs, both old file and new file to get the diff and the process might differ to get these, based on how is the swagger spec handled in your case.

[leowestx]

Hi

Thank you for taking your time to answer all my questions.

In my case it should be #2) Bottom-Up for me.

On Mon, 18 Apr 2022 at 5:40 PM, psrabhishek @.***> wrote:

Hello,

Before I can answer #1 https://github.com/psrabhishek/vscode-swagger-diff/issues/1, I want to ask about your #2.

There are different approaches for developing webservice and the specification provided to consumers.

1.

Top-Down : first we define the specs(swagger, openAPI, XML schema, etc), it could be hand-typed, where the developer/product owner will define the spec and development is done abiding to the spec defined. we can check-in or commit these specs in our git repo if needed. 2.

Bottom-UP: We develop our webservices first, and generate the spec (swagger, openAPI, XML schema, etc) from our developed code. In this case the spec might not be checked-in into git repo and could be generated at build time.

No matter the approach we need to have the spec file to with the consumers of our webservices.

So, to answer your #2, you should be the one knowing about the swagger.json being checked-in or generated in case of your product/application.

I will answer you other question once you get clarity on this. Since we need 2 inputs, both old file and new file to get the diff and the process might differ to get these, based on how is the swagger spec handled in your case.

— Reply to this email directly, view it on GitHub https://github.com/psrabhishek/vscode-swagger-diff/issues/1#issuecomment-1101113215, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYXRIT2POCS3JWPLMBXI6ATVFTYT3ANCNFSM5TQINNZA . You are receiving this because you were mentioned.Message ID: @.***>

[psrabhishek]

Hello,

Can you confirm if the swagger is committed into git repo.

If it is not committed into git repo, first you need to figure out how to get the Old Swagger Spec file as well, since the diff would be between Old spec and New spec.