Build and publish on GitHub
Last modified: 14 December 2024If your documentation sources are hosted on GitHub, you can use GitHub Actions to build your documentation website and deploy it to GitHub Pages.
tip
For more information about hosting your documentation sources on GitHub, see Git integration.
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
:
build-docs.yml
{...}
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 ishi
. So in this case, set the variable toWriterside/hi
.- env.DOCKER_VERSION
The version of the Writerside Docker builder to use for generating the documentation artifacts. The current latest version is 243.22562.
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:
Checkout the project repository using the actions/checkout@v4 action.
Generate the documentation website using the JetBrains/writerside-github-action@v4 action.
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.
build-docs.yml
{...}
After you commit and push this workflow, the test
job will run only if the build
job finished successfully, and it consists of the following steps:
Download the
docs
artifact into artifacts using the actions/download-artifact@v4 action.Parse report.json using the JetBrains/writerside-checker-action@v1 action, which fails the job if there are errors in the build report.
Build, test, and publish to GitHub Pages
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.
Configure the web path for images
In the writerside.cfg file, set the
web-path
parameter in the<images>
element to the GitHub repository name, for example:<ihp version="2.0"> <topics dir="topics"/> <images dir="images" web-path="my-docs-repo"/> <instance src="hi.tree"/> </ihp>
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.
build-docs.yml
{...}
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:
Download the
docs
artifact using the actions/download-artifact@v4 action.Unzip the website archive using the
unzip
command.Enable GitHub Pages using the actions/configure-pages@v4 action.
Package and upload an artifact that can be deployed to GitHub Pages using the actions/upload-pages-artifact@v3 action.
Deploy the artifact to GitHub Pages using the actions/deploy-pages@v4.
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
note
You can find the application ID and API keys in your Algolia account settings under API Keys.
Specify your private API key as a secret. The workflow will reference it via
${{ secrets.ALGOLIA_KEY }}
.
For example:
ALGOLIA_APP_NAME: 'NLAGB2LZHU'
ALGOLIA_INDEX_NAME: 'MY_INDEX'
CONFIG_JSON_PRODUCT: 'HI'
CONFIG_JSON_VERSION: '1.0'
Here is how it all comes together in a single workflow file:
build-docs.yml
{...}
Build to PDF
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:
name: Build to PDF
{...}
note
You should have the PDF.xml file in the cfg directory. For more information, see Export to PDF.
Thanks for your feedback!