Aller au contenu

Release workflow

TikZJax release automation is tag-driven.

The version in package.json is the release version source used by the GitHub workflows.

Before committing

Run the reproducible install and full checked build:

yarn install --immutable
yarn bfc

When documentation integration matters, also run:

yarn vendor:check
yarn dev

Set the version

Update package.json to the target version, for example:

1.x.y

The release tag must then be exactly:

v1.x.y

Both the GitHub Release workflow and the npm publication workflow reject a tag that does not match package.json with the leading v.

Commit and push

Typical sequence:

git add .
git commit -m "Release 1.x.y"
git push

Create and push the tag

git tag v1.x.y
git push origin v1.x.y

Pushing the tag triggers two independent workflows.

GitHub Release

.github/workflows/release.yml:

  1. verifies that the tag matches package.json;
  2. creates release notes from the tagged commit;
  3. creates the GitHub Release.

npm publication

.github/workflows/npm-publish.yml:

  1. verifies the tag/version match;
  2. checks out the known-good rod2ik/cdn runtime;
  3. configures the pinned Node/npm/Yarn toolchain;
  4. installs TeX Live dependencies;
  5. runs yarn install --immutable;
  6. prepares required runtime assets;
  7. runs yarn bfc;
  8. replaces the TeX runtime in dist/ with the known-good CDN runtime;
  9. verifies the npm package contents;
  10. publishes @rod2ik/tikzjax to npm.

This workflow deliberately protects publication from accidentally packaging an incomplete local runtime.

CDN deployment

After the release state has been validated, the existing helper is:

yarn deploy:cdn "commit message"

Keep the npm package, GitHub Release, CDN runtime, and documentation version aligned when completing a release.

GitHub Pages

The documentation workflow is separate from npm publication. At present, the published Pages site loads the released npm/jsDelivr TikZJax assets, while local yarn dev loads the generated local vendor.