-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[WIP]Make a common template for /api pages #18573
Conversation
851cb20
to
6ae3347
Compare
261d00f
to
ed6b5bf
Compare
Thanks for the review @timabbott ! I have addressed the comments, and am fixing the currently failing tests. The PR should be ready for another review by tomorrow. |
e3492d2
to
c581c15
Compare
@timabbott Managed to delete 58 files :) |
6e5f38a
to
d6f7deb
Compare
@@ -129,6 +129,8 @@ def extract_code_example( | |||
def render_python_code_example( | |||
function: str, admin_config: bool = False, **kwargs: Any | |||
) -> List[str]: | |||
if function not in zerver.openapi.python_examples.TEST_FUNCTIONS: | |||
return [] |
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.
Do we consider it a bug to have any endpoint without a Python code example? If so, we could consider raise AssertionError()
here, rather than return []
, so that it's not a silent failure.
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.
Currently, the two fetch-api-keys endpoints don't have python examples -- hence the empty string.
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.
OK, cool. I think we probably want to add them and then make this obligatory in a follow-up PR.
I merged 4 early commits as the series ending with e892a02. I agree that the output looks great; essentially all the changes are bug fixes :). Posted a comment on the Python commit, but I don't think it's a blocker for merging (since we can always fix that forward). I think I agree with your thoughts on which of these can be readily deleted; we should fix the |
@timabbott Apologies for the unnoticed bug.... Didn't realise it since all the tests had passed in the end. |
ba344a9
to
fcd8522
Compare
@@ -142,7 +142,7 @@ def test_doc_endpoints(self) -> None: | |||
self._test("/api/get-events", "dont_block") | |||
self._test("/api/delete-queue", "Delete a previously registered queue") | |||
self._test("/api/update-message", "propagate_mode") | |||
self._test("/api/get-own-user", "takes no parameters") | |||
self._test("/api/get-own-user", "does not accept any 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.
We don't want to have a commit where master fails tests, which the previous setup arranges. We can address this by just moving this before the previous commit, and manually changing that file to use the standard string. I'll do that while merging.
We use the "does not accept any parameters" language in the common template that we'll be migrating to shortly, so we remove this variance (And adjust its test).
The check for whether to do the special GET /events logic was incorrectly also covering DELETE /events.
Currently, the message that no parameters are accepted by the endpoint is displayed if there are no parameters in OpenAPI data, but it is possible that information is encoded in x-parameter-description (example in upload-file endpoint), and we want to display that information rather than the message. Added an if condition to check the same.
As a part of goal of moving towards a common template, the hardcoded python tabs need to be removed to ensure that endpoints which don't have python examples can be covered by the common template as well. This commit also modifies the markdown extension for python examples to render empty string in case the examples don't exist, which would allow it to be called whether the endpoint has python examples or not.
The returned values of get_path function would be expanded soon, and defining a dataclass would make the code cleaner for returning and using the fields.
The ArticlePath dataclass added can now be used for the return value of get_path function to make it more extensible and robust.
This PR adds a basic .md template that is followed by lot of /api pages. Since we have recently done the migration work to ensure that our REST API documentation pages for individual endpoints are almost all identical files following a common pattern, we can now get the payoff of deleting them all in favor of a shared template. This removes 2000 lines of somewhat finicky configuration from the codebase, and thus should save significant effort when documenting new API endpoints in the future. The markdown files for endpoints or other pages which deviate from the standard template remain, and the docs are instead generated from those files using the existing system.
fcd8522
to
23b991a
Compare
Merged after the small update above and also squashing the "add template" and "use template" commits. Huge thanks for doing this giant migration @MSurfer20! A few notes on near-term follow-ups:
|
This was a bug introduced in d0e44ea, whichw as missed due to zulip#18573 proceeding to delete the file soon after.
This effectively reverts: - commit 0c4330f (zulip#18573) - commit 274f73d (zulip#18776) It doesn’t make sense for these two syntaxes to be entangled like this. Signed-off-by: Anders Kaseorg <anders@zulip.com>
This PR removes the need for multiple
.md
files and makes a common template to generate /api pages from the OpenAPI data. This is currently a WIP.Work plan:
summary
parameter in YAML.summary
parameter..md
file..md
file.curl
optionsTesting plan:
GIFs or screenshots: