Release workflow: build every version and attach jars; release 0.1.1-beta #12

2026-09-25T14:39:38Z

selimaj-dev commented

2026-09-25 14:39:38 +00:00

Summary

Release workflow (`.gitea/workflows/release.yml`)

Runs when a release is published:

Checks out the repo, including the common submodule.
Checks the tag against mod_version in gradle.properties, allowing a leading v. On a mismatch it fails immediately, with a message saying which to fix, before any build time is spent.
Sets up Java 21 (Temurin), with the Gradle cache.
Builds with ./gradlew buildAll, which remaps every versions/* project in parallel into build/allJars/.
Uploads each jar in build/allJars/ to the release through the Gitea API, using the automatic GITEA_TOKEN (permissions: contents: write). If there are no jars, the job fails rather than leaving an empty release.

`mod_version` is the single source of truth

The workflow never overrides the version, so local builds, the server's version check and the released jars always agree. Releasing becomes:

Bump mod_version in a PR, and merge it.
Publish a release tagged with that exact version, e.g. 0.1.1-beta.

This PR bumps mod_version from 0.1.0-beta3 to 0.1.1-beta.

Before releasing 0.1.1-beta

The server's default manifest only supports 0.1.0-beta3. Set SUPPORTED_VERSIONS=0.1.1-beta in Coolify, or deploy the upcoming server change with the new default. Otherwise the new client will warn that it's unsupported and refuse to connect.

Testing

The workflow YAML parses.
The tag check's shell logic, run against the real gradle.properties: 0.1.1-beta passes, v0.1.1-beta passes, and 0.1.2-beta fails.
Not run yet: the workflow itself. It only triggers on a published release, so the 0.1.1-beta release will be its first run. Things to watch on that run:
- that runs-on: ubuntu-latest matches the runner's label
- that the automatic token can upload release assets
- that the common submodule checkout works

🤖 Generated with Claude Code

## Summary ### Release workflow (`.gitea/workflows/release.yml`) Runs when a release is **published**: 1. **Checks out** the repo, including the `common` submodule. 2. **Checks the tag against `mod_version`** in `gradle.properties`, allowing a leading `v`. On a mismatch it fails immediately, with a message saying which to fix, before any build time is spent. 3. **Sets up** Java 21 (Temurin), with the Gradle cache. 4. **Builds** with `./gradlew buildAll`, which remaps every `versions/*` project in parallel into `build/allJars/`. 5. **Uploads** each jar in `build/allJars/` to the release through the Gitea API, using the automatic `GITEA_TOKEN` (`permissions: contents: write`). If there are no jars, the job fails rather than leaving an empty release. ### `mod_version` is the single source of truth The workflow never overrides the version, so local builds, the server's version check and the released jars always agree. Releasing becomes: 1. Bump `mod_version` in a PR, and merge it. 2. Publish a release tagged with that exact version, e.g. `0.1.1-beta`. This PR bumps `mod_version` from `0.1.0-beta3` to **`0.1.1-beta`**. ## Before releasing 0.1.1-beta The server's default manifest only supports `0.1.0-beta3`. Set `SUPPORTED_VERSIONS=0.1.1-beta` in Coolify, or deploy the upcoming server change with the new default. Otherwise the new client will warn that it's unsupported and refuse to connect. ## Testing - The workflow YAML parses. - The tag check's shell logic, run against the real `gradle.properties`: `0.1.1-beta` passes, `v0.1.1-beta` passes, and `0.1.2-beta` fails. - **Not run yet:** the workflow itself. It only triggers on a published release, so the `0.1.1-beta` release will be its first run. Things to watch on that run: - that `runs-on: ubuntu-latest` matches the runner's label - that the automatic token can upload release assets - that the `common` submodule checkout works 🤖 Generated with [Claude Code](https://claude.com/claude-code)

selimaj-dev added 2 commits 2026-09-25 14:39:39 +00:00

Add release workflow that builds every version and attaches the jars 6ee8b64a38

On a published release, build all versions with buildAll using the tag
as the mod version, and upload build/allJars/*.jar to the release.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Make mod_version the source of truth for releases; bump to 0.1.1-beta 806c4ab643

The release workflow no longer overrides mod_version from the tag.
Instead it fails early unless the release tag (optionally prefixed with
"v") matches mod_version in gradle.properties, so released jars always
report the same version as the code the version check sees.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

selimaj-dev merged commit 79719262a2 into master

2026-09-25 14:39:58 +00:00

selimaj-dev deleted branch release-workflow

2026-09-25 14:40:01 +00:00

selimaj-dev referenced this pull request

2026-09-29 16:35:15 +00:00

Hide the cloak on torso-curving emotes and point common at #12 #45

selimaj-dev referenced this issue from a commit

2026-09-29 16:35:29 +00:00

Merge pull request 'Hide the cloak on torso-curving emotes and point common at #12' (#45) from release-fixes into master

Sign in to join this conversation.