-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[OAS] Add saved objects openAPI folder #162522
Conversation
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
Pinging @elastic/kibana-docs (Team:Docs) |
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.
Generally looks ok w.r.t actual API definitions.
I have a few comments and suggestions that don't necessarily need to be addressed now if the PR is urgent.
Please do take note of them though.
The current self-contained spec file is `bundled.json` or `bundled.yaml` and can be used for online tools like those found at <https://openapi.tools/>. | ||
This spec is experimental and may be incomplete or change later. | ||
|
||
A guide about the openApi specification can be found at [https://swagger.io/docs/specification/about/](https://swagger.io/docs/specification/about/). |
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.
AFAIK, every api that has an openApi spec will have a README
. That's a lot of duplication and adds to the bundle size. The original intent of moving kibana to packages was to keep Kibana small (codes size wise) and fast.
For now, it's probably ok but we need to watch that. @elastic/kibana-operations are we at all concerned about bundle size increasing?
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.
Agreed, if there are any space savings that can occur that's worth doing. Once we get to the point where the specs are being generated from the code there will hopefully be a lot less overhead too.
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.
We can keep an eye on it, thanks for the heads up. We're removing most documentation from the distribution currently, unless it's referenced in kibana itself.
Then you can generate the `bundled` files by running the following commands: | ||
|
||
```bash | ||
npx @redocly/cli bundle entrypoint.yaml --output bundled.yaml --ext yaml |
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.
Doesn't work as written.
e.g. locally, I get:
Error opening file "/Users/christianeheiligers/Projects/kibana/entrypoint.yaml"
ENOENT: no such file or directory, open '/Users/christianeheiligers/Projects/kibana/entrypoint.yaml'
If we're going to stick with a README
in every package, we need working code snippets.
This works:
npx swagger-cli validate entrypoint.yamlackages/core/saved-objects/docs/openapi/entrypoint.yaml
How is bundling supposed to work?
The code snippet creates a bundle locally at the root level of Kibana code. Won't that be replaced every time a new bundle get's created?
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.
You're right, in other API readmes I mentioned that you have to run those from the directory where these specs are located. I'll update that.
packages/core/saved-objects/docs/openapi/components/examples/export_objects_request.yaml
Show resolved
Hide resolved
packages/core/saved-objects/docs/openapi/components/examples/import_objects_response.yaml
Show resolved
Hide resolved
💚 Build Succeeded
Metrics [docs]
History
To update your PR or re-run it, just comment with: |
Summary
Relates to #137240
This PR drafts openAPI specifications for import objects and export objects
The assumption is that as we determine how/if the specifications differ for Serverless, we can create a
entrypoint-serverless.yaml
file and re-use as much content as possible.