-
Notifications
You must be signed in to change notification settings - Fork 58
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
chore(docs): improve devsite structure #962
chore(docs): improve devsite structure #962
Conversation
Here is the summary of changes. You are about to add 96 region tags.
You are about to delete 96 region tags.
This comment is generated by snippet-bot.
|
docs/standard_client/usage.rst
Outdated
@@ -1,10 +1,15 @@ | |||
Using the Sync Client | |||
===================== | |||
Standard Client |
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.
Is "Standard Client" a good name for this?
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.
Potentially? Not sure what's a good name for it though. Bigtable client
might be a more generically encapsulating name, but might be confusing with the API section right below it
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.
I would call it "classic api"
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.
Maybe "Classic Client"? There's the complication that we also have to communicate the differences between the admin api vs the data api, so API is a bit overloaded
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.
Classic client seems good
Added a feature to remove sections, and used it to remove the bottom "Bigtable" section. This section was a duplicate of the content we have in the two client folders |
docs/scripts/patch_devsite_toc.py
Outdated
|
||
def remove_sections(toc_file_path, section_list, output_file_path=None): | ||
""" | ||
Add new sections to the autogenerated docfx table of contents file |
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.
I think the doc is a copy/paste error?
docs/standard_client/usage.rst
Outdated
@@ -1,10 +1,15 @@ | |||
Using the Sync Client | |||
===================== | |||
Standard Client |
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.
Classic client seems good
Changes
Previously, the devsite page for bigtable was messy, combining pages for both clients into a single list:
This change adds a post-processing step to
docfx
, to add sections for the two client types to the table of contents, to keep things organizedImplementation Details
The table of contents on devsite is configured through
docs/_build/html/docfx_yaml/toc.yml
, which is generated uisngnox -s docfx
as part of the release pipeline.This PR adds a new script called
patch_devsite_toc.py
, which is added as a post-processing step to the end ofnox -s docfx
to add new sections to the auto-generated table of contents.As part of the PR, all pages specific to each client have been moved into subfolders in the
docs/
directory. These sub-folders can then be referenced bypatch_devsite_toc.py
when adding new sections to the table of contentsTo avoid docs issues in the future, I also added a verification step to the new script, to make sure the table of contents remains formatted as expected
Staged page available to reviewers on request