saturnclientmc/saturnclient
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases 5 Wiki Activity
902 Commits 1 Branch 21 Tags
7b312f54ae2b1fc616a152ccf5c5385d3efbac65
Commit Graph
7 Commits
Author SHA1 Message Date
selimaj-devandclaude b018db1851 Build with loom-back-compat and a Java toolchain per version 
Prepares the build for 26.x, which ships unobfuscated and needs Java 25
(#39):

- loom-back-compat applies the remapping Loom to 1.21.x and would apply
  the plain one to 26.x. loom_version becomes loomx.loom_version.
- Each version compiles with its Java toolchain (21 for 1.21.x, 25 for
  26.x), and the mixin configs take their compatibility level from it.
  The foojay resolver downloads a missing JDK; CI installs 21 and 25.
- buildAll collects remapJar's output, or jar's where there's nothing
  to remap.
- fabric.mod.json depends on fabric-api, Fabric API's mod id; 26.x's
  jar no longer provides the old "fabric" alias.

Nothing changes for the 1.21.x jars.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-30 19:15:02 +02:00
selimaj-devandclaude a8e6f14022 Fix the Release workflow's comment on how buildAll remaps
Check / compile (pull_request) Successful in 2m22s
Details 
Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-27 06:48:57 +02:00
selimaj-devandclaude 2ecb4f80ea Move setup-java to v5 and enable Gradle's build cache
Check / compile (pull_request) Successful in 9m39s
Details 
- setup-java v4 is deprecated; use v5 (still with `cache: gradle`,
  which works once job containers can reach the runner's cache server).
- Enable Gradle's build cache (org.gradle.caching) so unchanged
  compilations are restored from cache instead of re-run.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
 2026-09-26 03:19:11 +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