feat: Auto publish docs to version "develop"

[ijemmy]

Description of your changes

Auto publish docs to version "develop".

Every time we merge a change to main, we will publish a new version of document on "develop" version. (Instead of 1.1.0, 1.2.0, etc. which are published only when we release.). All of our docs are kept in the branch "gh-pages". The branch is special as it doesn't contain any source code, only published docs.

In the workflow, we publish the docs using two tools: mkdocs and mike. mkdocs generates a static website from ./doc into./site folder.

mike runs on the top of mkdocs to generate a new version into another directory. The idea of mike is that we keep the older version of doc published and never touch it. When we release a version 1.2.0, mike will create a new folder named 1.2.0 and put the new version of mkdocs generated site there. All of these happens in the "gh-pages" branch.

In this workflow, when we push to main branch, we will regenerate the special version "develop". This will replace the folder "develop" with the latest generated doc. (We also have the alias "latest" for the latest release version. This will be covered in the release workflow).

How to verify this change

Check out code from "gh-pages" branch. Run

cd develop
python3 -m http.server

You should see the mkdocs site in localhsot.

Related issues, RFCs

#152

PR status

Is this ready for review?: YES
Is it a breaking change?: NO

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• The code coverage hasn't decreased
• I have added tests that prove my change is effective and works
• New and existing unit tests pass locally and in Github Actions
• Any dependent changes have been merged and published in downstream module
• The PR title follows the conventional commit semantics

Breaking change checklist

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[dreamorosi]

LGTM :)