bass-foundry/docs/releases.md

Independent plugin releases on Gitea

Rivet and Patina have independent versions and releases. Workflows live under .gitea/workflows/.

Tag	Gitea release	Windows download
rivet-v0.3.0	Rivet 0.3.0	rivet-windows-x86_64-0.3.0.zip
patina-v0.1.0	Patina 0.1.0	patina-windows-x86_64-0.1.0.zip

Make a release

1. Update the selected wrapper's Cargo.toml version and its docs/<product>/CHANGELOG.md. The wrapper version determines the release version; internal crate versions can evolve separately.
2. Refresh affected lockfiles, run the product check, and commit/push the change.
3. Tag the intended commit and push that product's tag.

For Rivet:

python scripts/check-plugin.py --plugin rivet
git tag -a rivet-v0.3.0 -m "Rivet 0.3.0"
git push origin rivet-v0.3.0

For Patina:

python scripts/check-plugin.py --plugin patina
git tag -a patina-v0.1.0 -m "Patina 0.1.0"
git push origin patina-v0.1.0

These are instructions; this change does not create tags or publish a release. Tags must exactly match the selected wrapper version and a changelog section. Wrong product/version tags fail before building or publishing. Cargo prerelease versions such as patina-v0.2.0-rc.1 are supported and marked as prereleases.

Workflows

Check and Windows preview runs on branch pushes, pull requests, and manual dispatch. It checks both products, renders editor previews, and provides a combined Windows ZIP as an Actions artifact. It never publishes a release.

Independent plugin release runs on rivet-v* or patina-v* tag pushes:

1. plan validates the product/version/changelog and exposes the selected plugin.
2. build checks and cross-compiles only that plugin, then packages its Windows binary, documentation, licenses, internal checksums, and ZIP SHA256 sidecar.
3. publish downloads those exact artifacts and creates a Gitea draft release. It uploads the ZIP and checksum as release attachments, then publishes the release only after both attachments are present.

Release attachments are independent of the 30-day Actions artifact retention. The Gitea release page provides the persistent Windows and checksum downloads. Private repositories keep their usual download access requirements.

Runner and authentication

Enable Actions in the repository and provide a Docker-capable Gitea runner with the ubuntu-latest label. Jobs use node:22-bookworm so JavaScript actions have a Node runtime, and a local composite action installs Rust and build dependencies. Windows binaries are cross-compiled with MinGW; no Windows runner or Linux release binary is required.

Build cache

Every Rust job restores two caches through the runner's cache server (actions/cache@v4, run from the setup composite action):

• Toolchain: rustup's stable toolchain, Cargo's binaries, and the registry and git sources, keyed by ISO week, Windows target, and all three Cargo.lock files.
• Build directories: each job's target directories (check per plugin, previews, Windows preview, release per plugin), keyed the same way.

A new week or a changed lockfile starts a fresh entry, so stale build output does not accumulate and the stable toolchain refreshes weekly. Within a week, pushes reuse compiled dependencies and rebuild only this repository's crates. Release jobs use their own entries and never reuse branch build output. A cache miss only costs time. The runner's cache server must be enabled (cache.enabled in act_runner's config, the default) and must support post steps of actions inside composite actions (current act_runner releases do).

The workflows use explicit action URLs and the v3-compatible artifact protocol. Only the publish job requests contents: write. It authenticates against the same Gitea instance using the automatic secrets.GITEA_TOKEN; no personal access token is required. Repository/owner maximum token permissions must allow release writes. The runner needs access to the Gitea instance, action repositories, and build dependencies.

References: Gitea Actions quick start, job-token permissions, release creation API, and release attachment API.

Retries

Publication reuses matching attachments, preserves existing release notes, and repairs incomplete draft uploads. An existing attachment with different bytes is never replaced. Retry the publish job with its original build artifacts; changing the compiler or build environment can change a binary even for identical source. ZIP metadata is deterministic, but that is not a cross-toolchain guarantee.

The release tag must already exist in Gitea; the publisher does not create tags. The ZIP must contain exactly the selected plugin. Its sidecar and internal file checksums are verified before any release write.

Choose a plugin's named release/tag rather than assuming the repository's global latest release refers to both products. Package and API behavior are tested with fake transports; an actual runner/tag release on this Gitea instance remains to be verified.