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

Fix for issue#153-relative server paths in OpenAPI #181

Merged
merged 20 commits into from
Aug 23, 2021

Conversation

jaishirole
Copy link
Contributor

@jaishirole jaishirole commented Aug 6, 2021

Issue reference: #153

  • OpenAPI V3 allows servers to be at root, path or at operations level.
    The relative path could show up in any of these places.
    The PR tries to address that when SwaggerParser is given an URL to load the file. The fix doesn't work for non http(s) urls or local file system uploaded files.
  • For unit test, I've used a petstore file, which has relative paths. However, for other case of servers at path/operation, I have tested it by hosting a file on a cloud site. But, do not have a place to host there forever. Other possibility is mocking and using a file that is resident in the codebase. But, let me know your suggestion.

@jaishirole
Copy link
Contributor Author

@philsturgeon @P0lip
This is my first PR, please review and let me know your comments.
I would also need your help to trigger the pipeline tests for sanity of the PR.
I've locally run the unit tests and they're passing, except a known failure of unsupported 3.1.0 version in real-world APIs test suite.

@jaishirole jaishirole changed the title FIx for issue#153-relative paths in OpenAPI FIx for issue#153-relative server paths in OpenAPI Aug 6, 2021
@jaishirole jaishirole changed the title FIx for issue#153-relative server paths in OpenAPI Fix for issue#153-relative server paths in OpenAPI Aug 6, 2021
@philsturgeon
Copy link
Member

Sorry @jaishirole, bagsy not it. I'm out in the mountains on a big vacation and cannot help.

@P0lip if you're around can you help? Or can you pass it over to somebody who can?

const fetch = require("node-fetch");
const {expect} = require("chai");

const RELATIVE_SERVERS_OAS3_URL = "https://petstore3.swagger.io/api/v3/openapi.json"; //Petstore v3 json has relative path in "servers"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for this PR, glad I'm getting a chance to review it now!

I would prefer to avoid adding dependencies to random URLs, as it can have impacts on stability of the test suite (already not good), and can make things hard for those on unstable or highly locked down environments.

Could you create the smallest replicatable file and save it in there, like test/specs/deep-circular/deep-circular.yaml has done. Then this test will not need to go over the wire.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Phil @philsturgeon , thanks much for the review comment. I'll have to mock the fetch from an https URL to get the proposed changes tested without going over the internet. Let me add that and push a commit by tomorrow.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Phil @philsturgeon , please take a look at the latest push. I had to resolve conflicts as the upstream repo had new changes on 08/15. So, there are some merge conflicts that I had to solve. I was able to mock the http url fetch and even added more test cases. Let me know your review comments. Thanks!

Copy link
Member

@philsturgeon philsturgeon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good. If you could trim down the test files I'll be happy to merge this one! Thank you 🕺🏻

Comment on lines 25 to 46
"tags": [
{
"name": "pet",
"description": "Everything about your Pets",
"externalDocs": {
"description": "Find out more",
"url": "http://swagger.io"
}
},
{
"name": "store",
"description": "Operations about user"
},
{
"name": "user",
"description": "Access to Petstore orders",
"externalDocs": {
"description": "Find out more about our store",
"url": "http://swagger.io"
}
}
],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for these updates. when I mentioned making the smallest recreatable fixture files i meant can you trim them down a bunch so its easier to see what theyre actually doing? These megafixtures tend to get used for multiple things as people "find the most relevant one" and that leads to brittle test suites over time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, Phil! Let me trim the size further.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed the new commit, Phil.

]
}
},
"/pet/findByStatus": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could probably wipe out all paths other than the one you need to test, trim off parameters, etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, let me keep it to a smaller size.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed the new commit, Phil.

@jaishirole
Copy link
Contributor Author

Phil @philsturgeon , did the last push too! Hope you'll like it, halved the size of the json files but no compromise on what we wanted to test. :)

@jaishirole
Copy link
Contributor Author

I'm on it to fix the lint errors, not sure why my VS Code didn't catch it earlier.

@jaishirole
Copy link
Contributor Author

@philsturgeon
I pushed another commit to address the lint errors that showed failures in checks. That has overridden your approval. Can you help run the workflows again? Locally npm run lint doesn't show any errors now and the unit tests too are passing still.

@jaishirole
Copy link
Contributor Author

Hi Phil @philsturgeon , it looks like the usage of 'Optional chaining' aka ? in my code is causing a problem with some of the tests: node12 on Ubuntu and Browser Tests. I guess I need to move away from ? as it probably is perceived to be used only as a ternary operator by these test environments?

@jaishirole
Copy link
Contributor Author

Hi Phil @philsturgeon , it looks like the usage of 'Optional chaining' aka ? in my code is causing a problem with some of the tests: node12 on Ubuntu and Browser Tests. I guess I need to move away from ? as it probably is perceived to be used only as a ternary operator by these test environments?

@philsturgeon Another push for moving away from ? chaining parameter. Please help to kick off the check workflows.

@jaishirole
Copy link
Contributor Author

Phil @philsturgeon , the browser tests failed for not having the 'url' module available there. I've changed the code to use the 'url' exported from existing dependency of @apidevtools/json-schema-ref-parser which takes care of browser v/s node environments.
Now the npm run coverage:browser is passing on my local system where I've Firefox & Safari browsers.
image

If you trigger the checks workflow, looking forward to next results now.

@jaishirole
Copy link
Contributor Author

Hi Phil (@philsturgeon ) , not sure what the latest failure is about. Can you help me understand what is still left?
I guess it failed for?

18 08 2021 21:01:36.741:ERROR [launcher]: No binary for Edge browser on your platform.
  Please, set "EDGE_BIN" env variable.
18 08 2021 21:01:36.995:ERROR [launcher]: No binary for Safari browser on your platform.
  Please, set "SAFARI_BIN" env variable.

@jaishirole
Copy link
Contributor Author

@philsturgeon I am seeing what was reported here: #178 (comment) and perhaps it is a known issue and nothing with the code checked-in here.

@philsturgeon philsturgeon merged commit 2f22fe7 into APIDevTools:main Aug 23, 2021
@jaishirole
Copy link
Contributor Author

@philsturgeon Thanks much for all your guidance on this first PR of mine!

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

Successfully merging this pull request may close these issues.

3 participants