CI & release

CI overview

The GitHub Actions workflow .github/workflows/forge-dist-verify.yml is responsible for verifying that committed dist/<ver>/ artifacts match a clean reproducible build.

High level:

  1. Select which versions to verify (based on changed paths, tags, or manual input).

  2. Build the selected versions in a clean checkout (ci-build/).

  3. Run python3 forge_cli.py verify-dist --version <ver> to diff committed dist/<ver> vs the reproducible build.

Tag convention

Tags matching forge-* are treated as release-like triggers. Examples:

  • forge-3.4.0-r1

  • forge-3.5.0-r1

For a committed dist/<ver>/ release, tag the already-verified commit:

git tag forge-<ver>-r1
git push origin forge-<ver>-r1

For the MuJoCo 3.6+ batch:

git tag forge-3.6.0-r1
git tag forge-3.7.0-r1
git tag forge-3.8.0-r1
git tag forge-3.8.1-r1
git push origin forge-3.6.0-r1 forge-3.7.0-r1 forge-3.8.0-r1 forge-3.8.1-r1

Release assets

For release-like tags, CI publishes two assets under the same GitHub Release:

  • dist-runtime.zip

    • runtime-only payload for downstream web hosts / apps

    • zip root matches the forge webroot (mujoco.js, mujoco.wasm, optional pthreads/, version.json)

    • excludes abi/

    • includes pthreads/ only when that variant exists under dist/<ver>/

  • dist-audit.zip

    • audit/debug payload for maintainers

    • zip root contains abi/ plus version.json

Local reproduction of the CI verify step

Create a second clean checkout (or directory) and build into it, then run:

python3 forge_cli.py verify-dist --version <ver> --ci-build-dir ci-build