build + ci

local build

git clone https://github.com/bottledpepsi/MineTuner-HUD.git
cd MineTuner-HUD
./gradlew build

Output jar lands in build/libs/. Fabric Loom + Gradle, splitEnvironmentSourceSets() on (see architecture.html#sourcesets for what that actually buys you). withSourcesJar() is enabled, so a sources jar builds alongside the main one automatically.

toolchain

Target/release is Java 25 (options.release = 25, plus a matching JavaLanguageVersion.of(25) toolchain block). Gradle will auto-detect or auto-download a JDK 25 toolchain if the JDK that launched Gradle itself is older — controlled by org.gradle.java.installations.auto-detect / .auto-download in gradle.properties, both true. This matters if you're launching Gradle from an IDE's bundled older JDK; you don't need to manually install 25 first, but the first build with a new toolchain will download one.

gradle.properties — version pins

property	value	notes
`minecraft_version`	`26.2`	—
`loader_version`	`0.19.3`	Fabric Loader.
`loom_version`	`1.17-SNAPSHOT`	build plugin.
`mod_version`	`1.1.1`	injected into `fabric.mod.json`'s `${version}` placeholder by `processResources`.
`fabric_api_version`	`0.156.0+26.2`	—
`cloth_config_version`	`26.2.155`	hard dependency, client-only (`clientImplementation`). Pinned to match `minecraft_version` — check linkie when bumping MC version.
`modmenu_version`	`20.0.1`	`clientCompileOnly` — not bundled, not a runtime dependency. Only used to compile `MineTunerModMenuIntegration` against ModMenu's API; the built jar has no hard dependency on it (see `fabric.mod.json`'s `suggests`, not `depends`).

Repositories declared beyond Loom's automatic Minecraft/library maven setup: https://maven.shedaniel.me/ (Cloth Config) and https://maven.terraformersmc.com/ (ModMenu).

fabric.mod.json highlights

"environment": "client" — the whole mod is client-only, not just the client sourceset.
Three entrypoints: main → MineTunerMod, client → MineTunerClient, modmenu → MineTunerModMenuIntegration (soft — only loaded if ModMenu is present).
Two mixin configs: minetuner.mixins.json (common, currently empty — no server-side mixins exist) and minetuner.client.mixins.json (client env only, holds ClientPacketListenerMixin).
depends: fabricloader >=0.19.3, minecraft >=26.2, java >=25, fabric-api *, cloth-config >=26.2.155.

ci — .github/workflows/build.yml

Two jobs, both ubuntu-latest, both JDK 25 via actions/setup-java@v4 (distribution: microsoft):

`build`

trigger steps

push to main/master, PRs into either, published releases checkout → setup JDK 25 → cache ~/.gradle/{caches,wrapper} keyed on hashFiles('**/*.gradle*', '**/gradle-wrapper.properties') → chmod +x gradlew → ./gradlew build → upload build/libs/*.jar as artifact mod-jar (if-no-files-found: error, so a silently-empty build fails the job instead of "succeeding" with nothing to show for it) → on a tag push, attach the jar to the GitHub Release via softprops/action-gh-release@v2.

trigger	steps
push to `main`/`master`, PRs into either, published releases	checkout → setup JDK 25 → cache `~/.gradle/{caches,wrapper}` keyed on `hashFiles('*/.gradle', '/gradle-wrapper.properties')` → `chmod +x gradlew` → `./gradlew build` → upload `build/libs/.jar` as artifact `mod-jar` (`if-no-files-found: error`, so a silently-empty build fails the job instead of "succeeding" with nothing to show for it) → on a tag push, attach the jar to the GitHub Release via `softprops/action-gh-release@v2`.

`dependency-submission`

trigger	steps
same as above	checkout → setup JDK 25 → `gradle/actions/dependency-submission`, pinned to a specific commit SHA (`af1da67850ed9a4cedd57bfd976089dd991e2582`, tagged `v4.0.0`) rather than a floating tag, with `permissions: contents: write` so it can post to the repo's dependency graph.

this docs site's own deploy

/docs is plain static HTML/CSS, zero build step, zero JS dependency, served directly by GitHub Pages off the main branch's /docs folder (or via the included Pages Actions workflow, if you'd rather deploy on push instead of relying on the classic branch-based Pages source — see .github/workflows/deploy-docs.yml). Editing a page is editing the HTML file directly; there is no templating layer, no static site generator, no node_modules.