GitHub Pages

The theme uses GitHub Pages and GitHub Actions to make the documentation publicly available.

Most projects build and deploy a new site every time the default branch (master) receives an update. When multiversion is enabled, GitHub Pages builds docs for all versions listed in the file

Enabling GitHub Pages

  1. Create a file named .github/pages.yaml in the project’s root repository.

  2. Copy the contents from this file into .github/pages.yaml.

  3. (Optional) If the repository default branch is not master, edit the configuration file to use the default branch name instead.

  4. Commit and push the changes to GitHub (default branch).

  5. Wait a couple of minutes; it might take a while until GitHub builds the site. If everything goes well, you will see the docs published under<repository-slug>.

Setting up a custom domain


You need access to the domain DNS configuration.

Follow the next steps to set up a custom domain:

  1. In the domain’s DNS configuration, create a new CNAME record that points <custom-sudomain> to

  2. Change html_baseurl setting in for the desired sub-domain name. For instance, we will use

  3. Once the DNS changes propagate (<24 h), the docs will be accessible from the custom domain name.

Disabling GitHub Pages

To disable the docs deployment temporarily, see Unpublishing a GitHub Pages Site.

Triggering builds manually

Re-running workflows is useful when:

  • The theme received an update. By running the last build manually, the documentation project will receive the latest version. Otherwise, the theme will be automatically updated when the default branch gets an update.

  • A previous version (branch or a tag) received a patch. Otherwise, the changes will not be reflected in production until the master branch gets an update.

To re-run a workflow see, Re-running a workflow.