Added support for multiple openapi specifications. #160
Conversation
cmd/root_command.go
Outdated
| rootCmd.Flags().StringP("ws-host", "v", "localhost", "Set the backend hostname for wiretap, for remotely deployed service") | ||
| rootCmd.Flags().StringP("spec", "s", "", "Set the path to the OpenAPI specification to use") | ||
| rootCmd.Flags().StringP("spec", "s", "", "List of paths to the OpenAPI specification to use") | ||
| rootCmd.Flags().StringSliceP("specs", "$", []string{}, "List of paths to the OpenAPI specification to use") |
There was a problem hiding this comment.
We've actually run out of alphabetic characters to use for arguments and cobra doesn't support more than one character.
$ is probably the least bad option if was want a short argument
There was a problem hiding this comment.
this works -- I was thinking in Perl, and it occurred to me that '@' would be appropriate for a list :)
There was a problem hiding this comment.
We could also try a capitalized character - not sure if that differentiates it in Cobra.
There was a problem hiding this comment.
drop the short arg. $ as an arg is just too odd. stick with --specs
There was a problem hiding this comment.
Actually, it looks like capitalization is fine.
If you're good with -S, then we can do that.
| // register spec service | ||
| if err = platformServer.RegisterService( | ||
| specs.NewSpecService(doc), specs.SpecServiceChan); err != nil { | ||
| specs.NewSpecService(primaryDoc), specs.SpecServiceChan); err != nil { |
There was a problem hiding this comment.
I didn't add support for being able to specify which specification to retrieve by this service, instead implementing the idea of a "primary specification"
We may want to have a discussion on this.
There was a problem hiding this comment.
To me, it seems like creating a primaryDoc for the SpecService does not fully finish the feature.
If I have multiple specs loaded, I would want to see those multiple specs in the UI
There was a problem hiding this comment.
But if we merge the specs into one document, this would not be a problem 🤔
There was a problem hiding this comment.
I'm just thinking about use cases.
The most likely scenario when I'm using the UI is probably to view a single specification.
The most likely scenario when having multiple specifications is when it's used in CI IMO.
I just don't think it's worth the effort to implement this at this time.
|
where da tests at 👀 |
|
Also, why not merge the specs so that they are in one document. That way, you don't have to refactor anything 🤔 |
The reason that we can't just do this, is that we need to track which specification is being validated against for dashboarding purposes. The unit of division in the OpenAPI specification. In order to get any useful reports out of wiretap, we need to be able to track which error corresponds to which specifications |
|
can you pull in the latest libopenapi and validator also? |
|
You need to change the build-report-ui:
name: Build wiretap monitor UI
runs-on: ubuntu-20.04Should be build-report-ui:
name: Build wiretap monitor UI
runs-on: ubuntu-latest |
|
Fixed the build and updated libopenapi and validator |
This MR added support for multiple OpenAPI specifications in wiretap.
The use-case is that a user running browser-based integration tests may want to validate against multiple specification during the testing.
I have kept backwards compatibility with the existing OpenAPI specification options, while also adding the following options:
On CLI:
In Config:
These two options are in addition to the two possible ways to specify a single contract.
Validation is handled by searching for the path in each specification through libopenapi-validator's
paths.FindPathfunction.The specific specification used for validation is also now recorded in the error response.
I think I've caught everything that this could possibly touch.