saturnclientmc/saturnclient
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases 5 Wiki Activity
814 Commits 1 Branch 21 Tags
41f9be8595ec88cd58289832820df4ad546b11b2
Commit Graph
7 Commits
Author SHA1 Message Date
selimaj-devandclaude f73f7e733c Add a version port script and a compile check for pull requests
Check / compile (pull_request) Successful in 18m7s
Details 
- scripts/port.sh ports a change made under versions/<from>/src to the
  other versions with `git apply --3way`: clean where files match,
  normal conflicts only where a version really differs. Supports
  uncommitted changes or --commit, --to, --dry-run, and detects changes
  already applied.
- .gitea/workflows/check.yml compiles every version on pull requests and
  pushes to master (--continue reports all failing versions).
- VERSION_GUIDE.md documents the layout, porting, and adding a version.

Closes #17, closes #18

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-26 02:41:22 +02:00
selimaj-devandclaude 5bcdc72b83 Publish to Modrinth with Node instead of Python 
actions/setup-python can only install Python on GitHub's Ubuntu images,
so it fails on this runner's job image ("version 3.12 ... was not found
for this operating system"). Every Gitea runner has Node, since it runs
JavaScript actions, so port the publisher to a dependency-free Node
script (fetch/FormData/Blob) and drop the setup step. Behaviour is
unchanged.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-25 19:16:55 +02:00
selimaj-devandclaude c54b5ae6d7 Add a manual workflow that publishes a Gitea release to Modrinth 
"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]>
 2026-09-25 19:11:41 +02:00
selimaj-devandclaude 04605f6855 Upload release jars through the public URL again, with a size guard 
gitea:3000 isn't resolvable from act_runner's job containers, which run
on their own Docker network. With the panorama downscaled in common the
jars are ~45 MB, under the Cloudflare tunnel's 100 MB request limit, so
upload through github.server_url again. Fail with a readable error
before uploading if any jar is 100 MB or more.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-25 18:31:14 +02:00
selimaj-devandclaude 80d478d2c9 Upload release jars through Gitea's internal address 
The Cloudflare tunnel in front of git.selimaj.dev rejects the jar
uploads with 413 Payload Too Large. Call the API at http://gitea:3000
instead, look the release up by tag, and add a workflow_dispatch trigger
that builds a given tag and attaches the jars to its existing release.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-25 17:32:52 +02:00
selimaj-devandclaude 806c4ab643 Make mod_version the source of truth for releases; bump to 0.1.1-beta 
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]>
 2026-09-25 16:34:03 +02:00
selimaj-devandclaude 6ee8b64a38 Add release workflow that builds every version and attaches the jars 
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]>
 2026-09-25 16:33:42 +02:00