Closed Eric-Arellano closed 5 months ago
Here, you can find a quick guide to set up your repository to use GitHub Pages.
[!WARNING] Before starting with the process, you need to add a new branch called
gh-pages
. This branch needs to have that name to ensure the workflows can deploy successfully. You can create it manually, or, in case you have the new workflows, it will be created automatically after the first deployment (Better option).
Once you have the branch gh-pages
created, you can follow the following steps:
Settings
Pages
Deploy from a branch
, under the Source
section on Build and deployment
gh-pages
branch and the / (root)
folder in the Branch
section on Build and deployment
After following these steps, you will be able to deploy your website. The default URL where you can find your site is https://\<userid>.github.io/\<repository-name>
For further information, you can see the GitHub Pages Quickstart.
As you have probably seen, GitHub launched a new method (currently in Beta) to deploy to GitHub Pages using GitHub actions, but we are still using a publishing source (gh-pages branch) for the deployment of the documentation. The reason behind this is the flexibility we have using a different branch to make incremental deployments.
Some projects have historical API versions and need to publish to the page without modifying what is live or without having to rebuild and re-deploy everything. The deployment with GitHub actions doesn't allow us to do that because the deployment is treated as an atomic operation that has to be performed at once.
Therefore, the more convenient approach is to continue deploying the documentation with a publishing source. Even though not all the projects use historical API versions, it's useful to have all the workflows ready for projects to deploy historical versions in the future and to maintain consistency between the ecosystem.
You can find more information about this in the following issues that explore the possibility of having, in the future, the option to download the live site from GitHub Pages to avoid the problem of rebuilding everything:
Rustworkx has been completed with: https://github.com/Qiskit/rustworkx/pull/1037 and the new home of the documentation is: https://www.rustworkx.org/
@Eric-Arellano can you make https://qiskit.org/ecosystem/rustworkx/ redirect to https://www.rustworkx.org/? It will help users with the old link. Thanks!
@mtreinish is way ahead of you :) He has a PR up for review to set up the redirect. Thanks @IvanIsCoding for your great work on this PR!
Qiskit Algorithms docs are now on github pages https://qiskit-community.github.io/qiskit-algorithms/ thanks to @arnaucasau for the updated workflow that does this.
At what point are the redirects from ecosystem going to be setup. Algorithms docs have been deployed to github pages for a while but are not yet redirecting. Asking since I am about to redeploy Finance, as the first of the apps, once the backported PR to change things passes and is merged, which will all need redirects once they are live on github pages. I can note here, like I did for the algos, when its done, but like algos they will need the redirects added.
Thanks to @arnaucasau Qiskit Finance docs are now published on qithub pages https://qiskit-community.github.io/qiskit-finance/ - English only at present. Do we want to populate the translations that exist before going further - i.e. changing About link and adding ecosystem redirect. Presently selecting anything other than English results in a 404 error since locales is empty for now.
Qiskit Optimization is done https://qiskit-community.github.io/qiskit-optimization/ Qiskit Machine Learning now too https://qiskit-community.github.io/qiskit-machine-learning/
~(Just leaves Nature - I'll update here when its done - needs some other CI failure taken care of first)~
Qiskit Nature is now done too https://qiskit-community.github.io/qiskit-nature/
So that's all the app repos done now; Finance, Machine Learning, Optimization and Nature. ~Except dealing with languages other than English, i.e. translations - see next comment.~
Update: 26 Jan 2024. @arnaucasau did PRs to gh_pages adding the translations. They are merged and now live - so I altered the docs links in the repos' About to the github pages since the docs are complete - well aside from changing some cross sites links either via intersphinx, if they are auto generated, or manually fixing them up. I see in translations interphinx links, like to qiskit, are still to qiskit.org. Changing the interphinx in conf.py will only fixup the English version right when docs are redeployed from the repo. If the translations are not going to be updated maybe its ok that they continue to go via redirects.
At what point are the redirects from ecosystem going to be setup.
Arnau will be adding them this week, although it sometimes takes 1-2 days for the cloud team to review and merge.
Do we want to populate the translations that exist before going further - i.e. changing About link and adding ecosystem redirect.
Yeah, I think that's a good idea. The translations team finalized a few days ago the translations, so Arnau is working on setting up the translations in GitHub Pages. Those will be a one-time deploy since we are no longer actively doing the translations program for Qiskit Ecosystem.
Experiments is done: https://qiskit-extensions.github.io/qiskit-experiments/
I noticed this above in the task list against Aer
There are existing redirect rules from qiskit.org/documentation to the aer site; these need to be updated.
This is also true (redirects from qiskit.org/documentation) for the apps as they were moved out of the main qiskit docs to ecosystem where they were before. Eg https://qiskit.org/documentation/nature which redirects to nature in ecosystem etc.
This is also true (redirects from qiskit.org/documentation) for the apps as they were moved out of the main qiskit docs to ecosystem where they were before. Eg https://qiskit.org/documentation/nature which redirects to nature in ecosystem etc.
Thanks, Steve. We got those covered, too. Arnau's PR is up for review 🙌
Can/should any branch protection rules be setup for gh_pages
. I see for a PR @arnaucasau did a to Finance for adding translations its already mergable with no approval - evidently I don't want to do things that get in the way of the auto publication when the docs are rebuilt, but unlike main
and stable
presently it has no rules at all.
For the apps, with the translations being added, I made the About link the github pages one. See the update in this comment https://github.com/Qiskit/ecosystem/issues/578#issuecomment-1908614267 for more info - though that kept things about the apps in one place (in that one comment mainly) I wondered whether it might not get easily noticed hence this additional new comment pointing that out.
Hi @woodsp-ibm , I think you should be able to set up a branch protection rule, and it's a good idea. The only thing to have in mind is to allow the workflow to force push to the branch as you said. I found we can allow specified actors to bypass a rule, so maybe this can help.
All sites are now deployed, and we have a PR to set up redirects for the final 3 projects. Excellent job, @arnaucasau, leading this change!
This only impacts sites hosted on qiskit.org. We need to:
tools/deploy_documentation.sh
andtools/rclone.conf.enc
.qiskit.org/documentation/my_project
also.Simple sites to migrate:
More complex because translations. TBD if we want to continue with this program.
More complex because Previous Releases feature:
For translations and previous releases, the challenge might be if we need to deploy the site as a single atomic unit. Right now, we deploy each subsite distinctly, like
/ecosystem/nature
for the current English docs, but/ecosystem/nature/locale/es_UN
for the Spanish docs; those deploys happen at different times. I'm concerned if GitHub pages makes us copy over the entire/nature
folder and all subfolders like translations in a single pass. But my fear might be unfounded! See https://github.com/Qiskit/rustworkx/issues/1035 for some experimentation.