🌊 Streams: Prepare API for publishing#213127
Conversation
|
Examples will be added once #212495 lands |
|
/ci |
…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/streams --include-path /api/fleet --include-path /api/dashboards --update'
…3/kibana into flash1293/experimental-api-docs
|
/ci |
|
/ci |
flash1293
added
release_note:skip
jbudz
left a comment
jbudz
left a comment
There was a problem hiding this comment.
.buildkite/scripts/steps/checks/capture_oas_snapshot.sh LGTM
miltonhultgren
left a comment
miltonhultgren
left a comment
There was a problem hiding this comment.
LGTM
I only wonder if perhaps it would make sense to split the public/internal API by file/folder as well?
Perhaps I'm being overly cautious but if I go into a folder like routes/public that might set my mindset to "this is a public API, I need to apply more care with any change I make/review here", compared to mixing the two visibilities in the same file where the only difference is the access setting which might not even change in most PRs that one reviews. WDYT?
|
Fair point @miltonhultgren, I agree. I will rearrange things, shouldn't be a big change. |
…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/streams --include-path /api/fleet --include-path /api/dashboards --update'
yngrdyn
left a comment
yngrdyn
left a comment
There was a problem hiding this comment.
LGTM, I liked the split between public and internal routes 🚀
|
Starting backport for target branches: 8.x https://github.com/elastic/kibana/actions/runs/13836058761 |
💚 Build Succeeded
Metrics [docs]Async chunks
History
|
💔 All backports failed
Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
Add streams API to documentation as an experimental feature <img width="2555" alt="Screenshot 2025-03-07 at 11 44 54" src="https://github.com/user-attachments/assets/f54e5e6e-0c20-4bad-9cff-27747d0f76e2" /> There are a couple of changes in here: * Split streams API in internal and public and mark the public parts as experimental * Add the public parts to the Kibana documentation * Add description and summary * Adjust the server repository wrapper to pass through summary and description # To test * Generate OAS bundle: `node scripts/capture_oas_snapshot --include-path /api/streams --update` * Apply overlays `cd oas_docs && make api-docs` * Make sure bump.sh is installed (`npm install -g bump-cli`) * Run for preview: `cd oas_docs && bump preview output/kibana.yaml` # Open questions * Does the split into public and internal make sense? * Is it a problem if this is visible in the user-facing documentation page before we actually release streams? Or would it be OK if the API is marked as experimental? (mostly a question for @LucaWintergerst ) --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
@flash1293 is there an issue for this? |
7 participants
Add streams API to documentation as an experimental feature
There are a couple of changes in here:
To test
node scripts/capture_oas_snapshot --include-path /api/streams --updatecd oas_docs && make api-docsnpm install -g bump-cli)cd oas_docs && bump preview output/kibana.yamlOpen questions