If your documentation sources are hosted on GitHub, you can use GitHub Actions to build your documentation website and deploy it to GitHub Pages.
Set up a GitHub Actions workflow
In the root of your project, create the .github/workflows/ directory to store workflow files.
In the .github/workflows/ directory, create a new YAML file named build-docs.yml.
Use this file to define the automated jobs that build, test, and publish your documentation.
Build documentation website
The following sample workflow will trigger on every push to the main branch in the repository and build the starter project, where the default module name is Writerside and the default instance ID is hi:
If necessary, set the correct values for environment variables:
env.INSTANCE
The name of the module and instance ID separated by a slash. The module name is the directory with writerside.cfg. It is designated by the icon in the Project tool window.
For example, the default module name in a starter project is Writerside and the instance ID is hi. So in this case, set the variable to Writerside/hi.
env.DOCKER_VERSION
The version of the Writerside Docker builder to use for generating the documentation artifacts. The current latest version is 243.21565.
When you update to a newer version of Writerside, set the new Docker builder version to ensure results similar to what you see in the local preview and local builds.
After you commit and push build-docs.yml, the Build documentation workflow will automatically trigger and run the build job. Go to the project repository on GitHub and open the Actions tab to see the workflow and the produced artifacts.
The build job runs on the latest Ubuntu virtual machine and consists of three steps:
Save the generated website archive using the actions/upload-artifact@v4 action as part of the docs artifact.
Test produced artifacts
The Writerside builder produces a report with all problems that occurred during the build. You can view this report manually or configure a separate job that automatically checks the report and fails the workflow if it contains errors.
Modify the workflow file from the previous example and add report.json to the docs artifact that the build job produces. Also, add the test job to the workflow.
You can publish the produced artifacts manually or in a separate workflow. However, if you want continuous delivery automation, configure a job in the same workflow that will deploy every successfully built and tested artifact to GitHub Pages.
Enable publishing to GitHub Pages
Open the repository on GitHub, click Settings, then click Pages under Code and automation, and then select GitHub Actions as the Source under Build and deployment.
Modify the workflow file from the previous example and assign write permissions for the id-token and pages scopes in your workflow. Also, add the deploy job to the workflow.
After you commit and push this workflow, the deploy job will run only if both build and test finish successfully, and it consists of the following steps:
If the workflow is successful, the deploy job will output the URL to the published documentation.
Upload search indexes
If you also configure Algolia search, you can modify the workflow further and add the publish-indexes job that will automatically update the search indexes after a successful deployment.
You will also need to add Algolia indexes to the docs artifact that the build job produces, and specify the following additional environment variables:
env.ALGOLIA_APP_NAME
Algolia application ID
env.ALGOLIA_INDEX_NAME
Name of Algolia index
env.CONFIG_JSON_PRODUCT
Help instance ID from the tree file or the value of the web-path attribute specified in writerside.cfg if it is different from the ID
env.CONFIG_JSON_VERSION
Help instance version (usually the same as the branch name) specified in writerside.cfg
You can configure a separate workflow or a job in an existing workflow to produce a PDF artifact. Here is an example of a separate workflow with a build-pdf job that produces a PDF: