Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is this project still alive? #25

Open
BenSayers opened this issue May 29, 2017 · 9 comments
Open

Is this project still alive? #25

BenSayers opened this issue May 29, 2017 · 9 comments

Comments

@BenSayers
Copy link

My team is currently exploring options for detecting breaking changes between Swagger files. After exploring what is available in the open source world at the moment this project seems the most mature, with the code being well structured and thoroughly tested 👍

We are juggling between contributing to this project or writing our own equivalent tool. Our concern with contributing to this project is there is there has not been a commit to this codebase in almost 5 months and a PR has been sitting in review for over 3 months.

Here is the list of swagger changes that this tool currently does not detect that we would be interested in adding support for (not comprehensive, just what we discovered during a few hours of spiking):

  • Adding a new status code
  • Changing an existing status code
  • Adding a response body
  • Making required response properties optional
  • Adding a max or min restriction to a numeric response property
  • Adding a max or min restriction to a numeric request property
  • Removing a response body
  • Removing a format from a response property

Is this project still alive?
If we were to start working on this would you prefer many smaller PR's or fewer larger PR's?

@ryandavis84
Copy link

+1 to this, I have been using this tool and it has worked great thus far. Having those extra features would be nice as well.

@stuartblair
Copy link

stuartblair commented Nov 16, 2017

@BenSayers @ryandavis84 Interested in this one too. It ticks a lot of boxes for our public api consumption. For our internal services we're using Pact, for consumer-driven contract tests. However for our public apis where we can't really tell what our clients are relying on, we'd love to use something like this.

@BenSayers
Copy link
Author

BenSayers commented Nov 16, 2017

@stuartblair keep an eye on this project, it doesn’t do much yet but I’m expecting my team to get around to making it feature complete within the next 6 months:
https://bitbucket.org/atlassian/openapi-diff

Also if you are using both Swagger and Pact you might be interested in this tool we developed to validate a Pact against a Swagger spec:
https://bitbucket.org/atlassian/swagger-mock-validator

@stuartblair
Copy link

@BenSayers Thanks Ben! I did spot the swagger-mock-validator while looking for a solution a couple of weeks ago. Looked like a nice way of combining the two so that the consumer interactions are validated against the swagger prior to the normal pact validation.

I'll keep an eye on them.
Thanks

@ryandavis84
Copy link

Thanks @BenSayers, ill look into your project. Theres been a lot of talk about pact we just haven't moved forward with it. Ill be open sourcing somewhat of a swagger contract fuzz testing tool i wrote in java sometime soon. Or hopefully soon.

@ryandavis84
Copy link

I also wanted to see what this would look like in java as a jar. Not sure how i feel about it but ill release it anyways. Makes it very easy to update with new rules. Trying to figure out how to get ready for OAS 3 though. I will share the project once i finish the last few rules.

@mhuisman
Copy link

I would be inclined to support a fork and expansion of committers list.

@ryandavis84
Copy link

As promised, its not 100% by any means but from what i can tell it works pretty well.
https://github.com/ryandavis84/swagger-java-diff-cli
Just need to add some null testing and reduce all the code duplication as I put this together quickly. I am thinking of splitting up some of the description rules as well as some of the summary and external doc rules since they live in many places.

@stuartblair
Copy link

@BenSayers would you mind reviewing
this PR to expose OpenAPIDiff for developers to use in addition to invoking it from the command line tool?
I'm exploring this as a way of creating a custom matcher for Chai along the lines of

    it('supports existing consumers', function() {
      expect(newSpec).to.supportExistingConsumersOf(publishedSpec);
    });

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants