![]() |
Rendering Engine 0.2.9
Modular Graphics Rendering Engine | v0.2.9
|
Continuous Integration (CI) and Continuous Deployment (CD) in this project define a structured workflow for building the Rendering Engine SDK for all supported platforms, generating project documentation, and publishing the resulting artifacts for download and online availability.
The CI/CD system ensures that: SDKs are built in a reproducible way for all supported platforms Documentation is generated from the current codebase Resulting artifacts are automatically uploaded to public endpoints
CI/CD for this project is handled through GitHub Actions.
The workflows are defined in:
.github/workflows/build.yml.github/workflows/release-sdk.yml.github/workflows/docs.ymlbuild.yml performs cross-platform SDK validation builds for:
The workflow is started manually using workflow_dispatch, allowing any selected branch to be validated without publishing a release.
Build results are stored as temporary GitHub Actions artifacts.
release-sdk.yml builds, validates, and publishes versioned SDK packages for Linux, Windows, and FreeBSD.
The engine version is read from the root CMakeLists.txt. The workflow creates a Git tag and a GitHub Release containing the platform-specific SDK archives.
Release publication is initiated manually through:
Repository → Actions → Publish SDK Release → Run workflow
A release should normally be created first as a draft, reviewed, and then published.
docs.yml generates the Doxygen documentation and deploys the resulting HTML site to GitHub Pages.
The workflow runs automatically when changes are pushed to main and can also be started manually using workflow_dispatch.
The resulting artifacts are published to: Documentation: https://docs.rendering-engine.alexander-obzherin.info SDK downloads: https://downloads.rendering-engine.alexander-obzherin.info
The workflow can also be started manually using workflow_dispatch.
To run the workflow manually:
This allows feature branches to be tested without automatically triggering CI on every feature-branch push.
Feature branches do not automatically trigger the SDK build workflow.
To test a feature branch:
Each successful platform build produces a versioned SDK archive:
Self-hosted runners are configured in the GitHub repository:
Select:
GitHub then provides platform-specific commands for:
The registration token shown by GitHub is temporary. Use the commands provided by GitHub when registering a new runner.
Open:
Select:
Create a directory for the runner, for example:
Run the download, checksum verification, extraction, and configuration commands provided by GitHub.
During configuration, use the additional label:
The resulting runner labels are:
The workflow selects the runner using:
Ensure that the Windows machine has all required dependencies installed. See Prepare Environment
The following tools must be available in PATH:
Open PowerShell and navigate to the runner directory:
Start the runner:
A successfully started runner displays:
Keep the terminal open while the runner is required.
GitHub does not provide a native FreeBSD runner option. The GitHub Actions Linux x64 self-hosted runner package is used on the FreeBSD build machine.
Open:
Select:
Create a directory for the runner, for example:
Run the download, checksum verification, extraction, and configuration commands provided by GitHub.
During configuration, use the additional label:
The resulting runner labels are:
The workflow selects the runner using:
Ensure that all Rendering Engine build dependencies are installed.
The following tools must be available:
The GitHub Actions Linux runner may fail during action preparation on FreeBSD with:
This can occur even when FreeBSD's native tar is available:
Expected output:
To provide a tar command in a runner-specific location, create a compatibility directory:
Create a dedicated runner startup script:
Add:
Make the script executable:
Start the runner using:
A successfully started runner displays:
Keep the terminal open while the runner is required.
The standardized development workflow, branching model, versioning rules, and release process are documented in: