Add a manual workflow that publishes a Gitea release to Modrinth #15

Merged
selimaj-dev merged 1 commits from modrinth-publish into master 2026-09-25 17:13:53 +00:00
Owner

Summary

A new "Publish to Modrinth" workflow (.gitea/workflows/modrinth.yml) that you run by hand, separate from the Gitea release workflow:

Publish a Gitea release ─▶ Release workflow (automatic): builds and attaches 8 jars
                              │  smoke-test a jar
Run "Publish to Modrinth" ─▶ publishes those same jars to Modrinth (no rebuild)
  • Inputs: tag (the Gitea release) and dry_run (check everything and print the plan, without uploading).
  • Script: .gitea/scripts/publish_modrinth.py, Python standard library only. For each saturn-client-<version>+<mc>.jar on the release, it creates a Modrinth version on project saturnclient (i6JDSY9x):
    • name Saturn Client <version>+<mc> and version_number <version>+<mc>, matching the existing 0.1.0-beta2+1.21.4
    • game_versions: [<mc>] and loaders: [fabric]
    • Fabric API (P7dR8mSH) as a required dependency
    • the Gitea release notes as the changelog
    • version_type taken from the tag: alpha / beta (also for rc and pre) / release
  • Checks before uploading:
    • the release exists
    • each jar's version matches the tag
    • Modrinth knows each Minecraft version
  • Safe to re-run: versions already on Modrinth are skipped.
  • Download URLs: jars are downloaded via github.server_url. Gitea reports asset URLs using its internal ROOT_URL (http://git.selimaj.dev:3000/...), which isn't reachable publicly.

Setup (once)

  1. Modrinth → Settings → PATs: create a token with only the "Create versions" scope.
  2. This repo → Settings → Actions → Secrets: add it as MODRINTH_TOKEN.

Testing

  • Local dry run against the real 0.1.1-beta release and the Modrinth project:

    • It found all 8 jars, and each public download URL is reachable.
    • All 8 game versions are known to Modrinth.
    • It would publish 0.1.1-beta+1.21.4 … +1.21.11 as beta.
  • An unknown tag gives "No Gitea release with tag …", and a missing token gives a readable message.

  • The workflow YAML parses and the script compiles.

  • Not tested yet:

    • the actual POST /v2/version upload, which needs the token
    • skipping existing versions

    Recommended first run: 0.1.1-beta with dry_run ticked, then without.

🤖 Generated with Claude Code

## Summary A new **"Publish to Modrinth"** workflow (`.gitea/workflows/modrinth.yml`) that you run by hand, separate from the Gitea release workflow: ``` Publish a Gitea release ─▶ Release workflow (automatic): builds and attaches 8 jars │ smoke-test a jar Run "Publish to Modrinth" ─▶ publishes those same jars to Modrinth (no rebuild) ``` - **Inputs:** `tag` (the Gitea release) and `dry_run` (check everything and print the plan, without uploading). - **Script:** `.gitea/scripts/publish_modrinth.py`, Python standard library only. For each `saturn-client-<version>+<mc>.jar` on the release, it creates a Modrinth version on project `saturnclient` (`i6JDSY9x`): - name `Saturn Client <version>+<mc>` and `version_number` `<version>+<mc>`, matching the existing `0.1.0-beta2+1.21.4` - `game_versions: [<mc>]` and `loaders: [fabric]` - **Fabric API (`P7dR8mSH`) as a required dependency** - the Gitea release notes as the changelog - `version_type` taken from the tag: `alpha` / `beta` (also for rc and pre) / `release` - **Checks before uploading:** - the release exists - each jar's version matches the tag - Modrinth knows each Minecraft version - **Safe to re-run:** versions already on Modrinth are skipped. - **Download URLs:** jars are downloaded via `github.server_url`. Gitea reports asset URLs using its internal `ROOT_URL` (`http://git.selimaj.dev:3000/...`), which isn't reachable publicly. ## Setup (once) 1. Modrinth → **Settings → PATs**: create a token with **only** the "Create versions" scope. 2. This repo → **Settings → Actions → Secrets**: add it as `MODRINTH_TOKEN`. ## Testing - Local dry run against the real `0.1.1-beta` release and the Modrinth project: - It found all 8 jars, and each public download URL is reachable. - All 8 game versions are known to Modrinth. - It would publish `0.1.1-beta+1.21.4` … `+1.21.11` as `beta`. - An unknown tag gives "No Gitea release with tag …", and a missing token gives a readable message. - The workflow YAML parses and the script compiles. - **Not tested yet:** - the actual `POST /v2/version` upload, which needs the token - skipping existing versions Recommended first run: `0.1.1-beta` with `dry_run` ticked, then without. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
selimaj-dev added 1 commit 2026-09-25 17:13:35 +00:00
"Publish to Modrinth" (workflow_dispatch, tag + dry_run inputs) takes the
jars the Release workflow attached to a Gitea release and creates one
Modrinth version per jar: version_number <version>+<mc>, that Minecraft
version, fabric loader, Fabric API as a required dependency, the release
notes as the changelog, and alpha/beta/release from the tag. It doesn't
rebuild, skips versions already on Modrinth, and downloads jars through
the public URL (Gitea's reported URLs use its internal ROOT_URL).

Needs a MODRINTH_TOKEN secret with the "Create versions" scope.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
selimaj-dev merged commit 3f0670ea9d into master 2026-09-25 17:13:53 +00:00
selimaj-dev deleted branch modrinth-publish 2026-09-25 17:13:56 +00:00
Sign in to join this conversation.