Regenerate openapi spec
- [ ] This change is worth documenting at https://docs.all-hands.dev/
- [ ] Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below
Summarize what the PR does, explaining any non-trivial design decisions.
Regenerate the openapi.json using the following command while running the backend:
curl -s http://127.0.0.1:3000/openapi.json | jq . > docs/static/openapi.json
When generating the API client I got a lot of errors and realised that the spec was totally wrong. We should probably add a build step to do this automatically.
The website is also all wrong as it is built from the openapi spec. As can be easily seen here api-reference/get-conversation where the trigger is listed as "GUI" but the actual value has now changed to
"enum": [
"resolver",
"gui",
"suggested_task",
"openhands_api",
"slack"
],
@theolundqvist are you planning on implementing a build step/fix, or just fixing the immediate issue?
If you're not planning on implementing the build step, could you open an issue and link to it so that long-term work doesn't get lost?
I wonder if we should just point this at that /docs of the saas env
I wonder if we should just point this at that /docs of the saas env
Depending on where the commercial offering goes, couldn't that lead to the spec having endpoints unavailable on the open-source project? This also wouldn't work for any branches outside of main if I understand the proposal right.
It now moved in #8848 , still not updated though
The static openapi.json file seems to have some custom modifications to it which would be overwritten by this change (for example, custom servers), and seems to be intended for use on the docs website. (Where it is mostly working).
I can't find any documentation on how it was originally produced, but I would suggest using the http://localhost:3000/openapi.json if you need this spec locally.
In the meantime, I think we need to introduce a process to keep this in sync while maintaining the custom changes.
I don't see how it makes any sense to keep documentation that is totally out of date. A very small fraction of the endpoints actually work in that old spec.