The repository uses Antora Playbooks to locally or remotely build the AsciiDoc content into a static website.
You need git to get the source code of this repository. Run the command below to check whether git is installed on your machine.
git --versionIf you don’t have git installed on your machine, download and install it for your operating system from the git downloads page.
Antora requires an active long term support (LTS) release of Node.js. Run the command below to check if you have Node.js installed, and which version. This command should return an active Node.js LTS version number
node -vIf you don’t have Node.js installed on your machine, install it, preferably via nvm
Run the git command to clone this repository.
git clone https://github.com/rancher/turtles-docs.gitOpen a terminal at the root of the git repository. Run the command below.
npm installYou can use the make command to build the documentation site locally or remotely. The Makefile defines various tasks for building the site using different playbooks.
To build the site locally using the GitHub Pages playbook, run the following command:
make gh-pagesThis will generate the static website using the turtles-gh-pages-playbook.yml playbook.
To build the site remotely using the remote playbook, run:
make remoteThis will use the playbook-remote.yml to generate the site remotely.
For development purposes, you can build the site using the development playbook by running:
make devThis will use the turtles-dev-playbook.yml to generate the site with development settings.
To remove the build and temporary directories, use the following command:
make cleanThis will delete the build and tmp directories.
To preview the site locally, use the preview task:
make previewThis will serve the site locally, allowing you to view it in your browser.
To watch for changes in the content and rebuild the site automatically, use the watch task:
make watchThis will watch the content and documentation files for changes, rebuild the site, and preview it with hot reload.
This section explains how Turtles documentation versions are managed and updated when new releases are published.
The documentation repository automatically updates versions when a new Turtles release tag is pushed to the main repository. Here’s how the process works: The version bump process is triggered automatically when:
-
A new version tag (format:
v*) is pushed to the rancher/turtles repository -
The GitHub workflow
.github/workflows/publish-version.yamldetects the tag and starts the process
The automation updates several types of version references throughout the documentation:
-
GitHub URLs: Raw GitHub links are updated from
refs/heads/maintorefs/tags/v{version} -
Environment Variables:
TURTLES_VERSIONvalues in code examples -
Helm Commands: Version flags in
helm installcommands -
Component Tables: Version references in component compatibility tables
The repository includes a custom Go tool at tools/setexampleversion/main.go that handles version replacements:
-
Configuration: Uses
replace-rules.jsonto define replacement patterns -
Flexible Rules: Each rule specifies a regex pattern and replacement template
Example usage:
go run tools/setexampleversion/main.go -version=v0.21.0 \
docs/v0.21/modules/en/pages/user/installation.adoc \
docs/v0.21/modules/en/pages/user/clusterclass.adocFor updating component versions (Rancher, Cluster API, etc.) in the prerequisites tables, the repository includes a reusable workflow at .github/workflows/pre-release.yaml. This workflow can be called from other workflows to selectively update component versions in the docs/next/ directory:
-
Selective Updates: Only updates versions for components that are specified as inputs
-
Automatic PR Creation: Creates a pull request with the version changes
-
Flexible Configuration: Each component version can be updated independently
For manual version updates or testing:
-
Update the config: Modify
replace-rules.jsonif new replacement patterns are needed -
Run the tool: Execute the version replacement tool with the desired version
-
Review changes: Check that all version references have been updated correctly
-
Test locally: Build and preview the documentation to ensure everything works
When new version references are added to the documentation:
-
Identify the pattern: Find the exact text pattern that needs version replacement
-
Add a rule: Update
replace-rules.jsonwith a new replacement rule -
Test the rule: Run the tool to verify the pattern matches correctly
-
Document the change: Update this README if the change affects the workflow
Example rule structure:
{
"name": "Description of what this rule updates",
"pattern": "regex-pattern-to-match",
"replacement": "replacement-template-with-%s-placeholder"
}