nvrl
15853e61ac
Check and Windows preview / check (patina) (push) Successful in 2m20s
Check and Windows preview / check (rivet) (push) Successful in 1m38s
Check and Windows preview / previews (push) Successful in 1m6s
Check and Windows preview / windows (push) Successful in 1m50s
Independent plugin release / publish (push) Successful in 8s
Independent plugin release / plan (push) Successful in 7s
Independent plugin release / build (push) Successful in 2m21s
95 lines
4.2 KiB
Markdown
95 lines
4.2 KiB
Markdown
# 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:
|
|
|
|
```sh
|
|
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:
|
|
|
|
```sh
|
|
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.
|
|
|
|
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](https://docs.gitea.com/usage/actions/quickstart/),
|
|
[job-token permissions](https://docs.gitea.com/usage/actions/token-permissions/),
|
|
[release creation API](https://docs.gitea.com/api/next/operations/repo-create-release/),
|
|
and [release attachment API](https://docs.gitea.com/api/next/operations/repo-create-release-attachment/).
|
|
|
|
## 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.
|