## Description This pr is meant to capture a conversation in slack and propose it to the community. The updated flow reduces boilerplate code and decreases the amount of duplicated validations happening. --- ### Author Checklist *All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.* I have... - [ ] included the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] added `!` to the type prefix if API or client breaking change - [ ] targeted the correct branch (see [PR Targeting](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#pr-targeting)) - [ ] provided a link to the relevant issue or specification - [ ] followed the guidelines for [building modules](https://github.com/cosmos/cosmos-sdk/blob/main/docs/docs/building-modules) - [ ] included the necessary unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/main/CONTRIBUTING.md#testing) - [ ] added a changelog entry to `CHANGELOG.md` - [ ] included comments for [documenting Go code](https://blog.golang.org/godoc) - [ ] updated the relevant documentation or specification - [ ] reviewed "Files changed" and left comments if necessary - [ ] confirmed all CI checks have passed ### Reviewers Checklist *All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.* I have... - [ ] confirmed the correct [type prefix](https://github.com/commitizen/conventional-commit-types/blob/v3.0.0/index.json) in the PR title - [ ] confirmed `!` in the type prefix if API or client breaking change - [ ] confirmed all author checklist items have been addressed - [ ] reviewed state machine logic - [ ] reviewed API design and naming - [ ] reviewed documentation is accurate - [ ] reviewed tests and test coverage - [ ] manually tested (if applicable) |
||
|---|---|---|
| .. | ||
| architecture | ||
| docs | ||
| rfc | ||
| spec | ||
| src/css | ||
| static | ||
| .gitignore | ||
| babel.config.js | ||
| build-all.sh | ||
| DOC_WRITING_GUIDELINES.md | ||
| docusaurus.config.js | ||
| package-lock.json | ||
| package.json | ||
| post.sh | ||
| pre.sh | ||
| README.md | ||
| sidebars.js | ||
| tailwind.config.js | ||
| versions.json | ||
| vuepress_versions | ||
Updating the docs
If you want to open a PR in Cosmos SDK to update the documentation, please follow the guidelines in CONTRIBUTING.md and the Documentation Writing Guidelines.
Stack
The documentation for Cosmos SDK is hosted at https://docs.cosmos.network and built from the files in the /docs directory.
It is built using the following stack:
-
Vuepress (pre v0.47)
-
algolia: { appId: "QLS2QSP47E", apiKey: "067b84458bfa80c295e1d4f12c461911", indexName: "cosmos_network", contextualSearch: false, }, -
GitHub Pages
Docs Build Workflow
The docs are built and deployed automatically on GitHub Pages by a GitHub Action workflow.
The workflow is triggered on every push to the main and release/v** branches, every time documentations or specs are modified.
How It Works
There is a GitHub Action listening for changes in the /docs directory for the main branch and each supported version branch (e.g. release/v0.46.x). Any updates to files in the /docs directory will automatically trigger a website deployment. Under the hood, the private website repository has a make build-docs target consumed by a Github Action within that repository.
How to Build the Docs Locally
Go to the docs directory and run the following commands:
cd docs
npm install
For starting only the current documentation, run:
npm start
It runs pre.sh scripts to get all the docs that are not already in the docs/docs folder.
It also runs post.sh scripts to clean up the docs and remove unnecessary files when quitting.
Note, the command above only build the docs for the current versions. With the drawback that none of the redirections works. So, you'll need to go to /main to see the docs.
To build all the docs (including versioned documentation), run:
make build-docs
What to for new major SDK versions
When a new major version of the SDK is released, the following steps should be taken:
-
On the
release/vX.Y.Zbranch, remove the deploy action (.github/workflows/deploy-docs.yml), for avoiding deploying the docs from the release branches. -
On the
release/vX.Y.Zbranch, updatedocusaurus.config.jsand set thelastVersiontocurrent, remove all other versions from the config. -
Each time a new version is released (on docusaurus), drop support from the oldest versions.
-
If the old version is still running vuepress (v0.45, v0.46), remove its line from
vuepress_versions -
If any, remove the outdated redirections from
docusaurus.config.jsand add the base version redirection (/vX.XX) to/main.{ from: ["/", "/master", "/v0.43", "/v0.44", "/v0.XX"], // here add the deprecated version to: "/main", },
-
-
Add the new version sidebar to the list of versionned sidebar and add the version to
versions.json. -
Update the latest version (
presets[1].docs.lastVersion) indocusaurus.config.js. -
Add the new version with in
presets[1].docs.versionsindocusaurus.config.js.
Learn more about versioning in Docusaurus.