-
Notifications
You must be signed in to change notification settings - Fork 15
feat: add slice command to filter OpenAPI specs #1056
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
Conversation
…ation IDs, and paths - Add new 'extract' CLI command to slice OpenAPI specifications - Support filtering by operation IDs, tags, and path patterns - Implement SliceFilter with comprehensive test coverage - Use Cobra's StringSliceVar for cleaner flag handling - Include all referenced schemas and components in output - Add validation for input parameters and output formats - Support both YAML and JSON output formats
- Update command name from 'extract' to 'slice' for consistency - Update all examples and documentation to use 'slice' - All tests still pass
- Fix perfsprint linter error - Use errors.New instead of fmt.Errorf when no formatting is needed - Add errors import
- Replace fmt.Errorf with errors.New for non-formatted errors (perfsprint) - Fix receiver naming consistency in SliceFilter.matches method (revive) - Change receiver name from 'e' to 'f' to match other methods
- Add ParametersFilter to remove unused parameters from OpenAPI specs - Add comprehensive tests for ParametersFilter (7 test scenarios) - Move slice functionality from filter package to dedicated slice package - Update FiltersToCleanupRefs to include TagsFilter, ParametersFilter, and SchemasFilter - Fix linting issues (import shadowing and missing period in comment) - Slice command now cleans up unused tags, parameters, and schemas automatically
| Version: "1.0", | ||
| }, | ||
| Paths: openapi3.NewPaths(openapi3.WithPath("/test/{id}", &openapi3.PathItem{ | ||
| Parameters: openapi3.Parameters{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you help me to understand the equivalent of this Parameters field under PathItem in the OpenAPI spec?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or, would it make more sense under Get operation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of course, so in this example the path is /test/{id} so the path parameter would refer to id and the type it references. All parameters types are under components.parameter in the OpenAPI spec with refer to path and query parameters. Since this is a parameter for the endpoint path, it is not associated with an operation (i.e. GET, UPDATE etc.) Let me know if this clarifies everything!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In our MMS OpenAPI spec we currently don’t use parameters in a way that applies to all operations under an endpoint. To stay consistent, it may be better to follow the same structure we already use
Based on the example, I would normally expect something like this to exist:
/test/{id}:
parameters:
- name: id
in: path
required: true
schema:
type: string
get:
…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yes I see that now, thank you for clarifying, will update the test cases for this!
| // Check if the path matches (with normalization) | ||
| normalizedPath := normalizePath(path) | ||
| for _, pattern := range criteria.Paths { | ||
| if normalizedPath == normalizePath(pattern) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[q] does the path mtaches nested resources? ie, if I provide --filterPath atlas/api/v2, will the slice command return an openapi spec with all the resources?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this PR, endpoint paths that match exactly will be selected in the output spec. I can add in a follow-up PR support for regex path matching
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, there is no need to add the logic if you won't use it. Just makes sure to include this clarification in the command or flag description
| if f.oas.Components == nil || f.oas.Components.Schemas == nil { | ||
| return nil | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in which scenario we have components or components.schemas nil? Note that when we load the spec with the openapi repo, we are also performing a validation that all the references in the endpoints are correctly in the component section
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was thinking for the scenarios where all the response / request bodies are inline for each API endpoint, in that case the Schemas could contain nothing
Proposed changes
This PR adds a new
slicecommand to thefoasclithat enables users to slice/filter OpenAPI specifications by operation IDs, tags, or path patterns. This feature allows developers to create smaller, focused OpenAPI specs containing only the endpoints they needExample usage:
Jira ticket: CLOUDP-365849
Checklist
Changes to Spectral
Further comments