Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
## Summary This PR changes the `docs.yml` and `docs_dev.yml` workflows to deploy the documentation to GitHub Pages to migrate the project away from the qiskit.org domain. More information about the change and a quick guide to set up GitHub pages can be found at: Qiskit/ecosystem#578 Reminder task for maintainers to update the docs link in the About text for the repo on the main page once this change happens and the docs are re-deployed. This will need backporting to stable branches. - [ ] Update About text doc link ## Details The PR adds three new workflows, replacing the ones used to deploy to qiskit.org (`docs.yml` and `docs_dev.yml`). The new workflows replicate the same structure used by the old workflows when the documentation was pushed to qiskit.org using the `rclone` command. The documentation will be deployed into the `gh-pages` branch where we will find the latest release in the root of the branch. In addition, we will have one folder named `stable/` for all the previous releases and a second one for the dev docs named `dev/`. gh-pages branch structure example: ``` |- unversioned docs |- stable/ |- stable version1/ |- stable docs |- stable version2/ |- stable docs |- dev/ |- dev docs ``` The three new workflows are: **docs_release.yml** (Docs Publish): This workflow allows us to deploy the docs to GitHub pages into the root of the `gh-pages` branch. This will be the unversioned release we will find on the website. **docs_stable.yml** (Stable Docs Publish): This workflow deploys the release we choose into the `stable/` folder. The documentation will be accessible using the `Previous Releases` collapsible menu in the sidebar. **docs_dev.yml** (Dev Docs Publish): Same workflow as `docs_dev.yml` but deploying the documentation to the `dev/` folder in the `gh-pages` branch. The `docs_release.yml` and the `docs_stable.yml` workflows split the current `docs.yml` workflow into two phases. This change is useful to have more control over what versions we want to deploy. With the old workflow, we needed to deploy everything in a specific order to have the latest version as the unversioned one on the website. With the two workflows, we will be able to re-deploy stable versions when necessary. --------- Co-authored-by: Helena Zhang <[email protected]>
- Loading branch information