Skip to content

feat: add reusable resource pack publish workflow - #25

Merged
TheMeinerLP merged 2 commits into
mainfrom
feat/resourcepack-publish
Aug 10, 2026
Merged

feat: add reusable resource pack publish workflow#25
TheMeinerLP merged 2 commits into
mainfrom
feat/resourcepack-publish

Conversation

@TheMeinerLP

Copy link
Copy Markdown
Contributor

Adds resourcepack-publish.yml — the missing piece for publishing Minecraft resource packs.
cygnus-pack needs it now; ManisPack has the identical structure and the same unsolved
problem, which is why this belongs in the catalogue rather than in one consumer.

What it does

Packs a pack-dir (default pack/) into a ZIP, uploads it to an S3-compatible store, and
announces it on Discord. Two channels off one implementation:

  • release — immutable versioned archives under releases/
  • snapshot — rolling builds under snapshots/, so development can test between releases

Toolchain-agnostic: it only turns a directory into a published archive, no build step.

Design notes

.sha256 beside every archive, plus a latest alias. This pairing is the whole point.
A server points permanently at <prefix>/<pack>-latest.zip and reads the expected hash from
the file next to it. Minecraft re-downloads a pack exactly when the hash it is handed changes,
so the URL in the server config never has to move. The alias gets its own checksum file
because sha256sum -c matches on the file name recorded inside it.

Reproducible ZIP (fixed file order, fixed timestamp, zip -X). Without it the SHA256
differs on every run and every player re-downloads an unchanged pack after every build.
Verified locally: two consecutive builds produce an identical hash.

s3-endpoint is an input, not a secret. GitHub masks secret values wherever they appear,
so an endpoint passed as a secret renders the download URL as *** in the job summary and in
every log line — the two places anyone actually looks for it. The endpoint is a public
hostname; the keys next to it stay secrets.

JSON validation before packing. A malformed model file otherwise fails silently in the
client: the item renders untextured with nothing in any log to trace it back to.

Context values reach the scripts through env: only, never interpolated into a run line, so
a quote character in any value cannot break the shell.

Verified

  • YAML parses; the build logic was exercised locally against a pack with a non-default
    pack-dir and pack-name: pack.mcmeta lands at the archive root, no wrapper directory,
    sha256sum -c validates, two builds produce an identical hash.
  • README.md passes markdownlint. The four pre-existing MD060 findings are unchanged from
    main — a newer rule than the CI action currently knows about, untouched here.

Also included

pr-lint.yml was missing from the catalogue table. Added, since it is the workflow that keeps
release-please from silently skipping a release under squash merges.

Follow-up

OneLiteFeatherNET/cygnus-pack#1 pins @v2.7.0 and can only be merged once this is released.

Packs a Minecraft resource pack directory into a reproducible ZIP, uploads it
to an S3-compatible store and announces it on Discord. Release and snapshot
channels share one implementation.

Every upload writes a .sha256 next to the archive plus a latest alias with its
own checksum file. A server can then point permanently at the latest URL and
read the expected hash beside it: Minecraft re-downloads a pack exactly when
the hash it is handed changes, so the URL never has to move per build.

The build is reproducible (fixed file order, fixed timestamp, zip -X). Without
that the SHA256 would differ on every run and every player would re-download an
unchanged pack after every build.

s3-endpoint is an input rather than a secret: GitHub masks secret values, so an
endpoint passed as a secret renders the download URL as *** in the job summary
and the logs.

Also documents pr-lint.yml in the catalogue table, which was missing.
A required workflow_call input still arrives as an empty string when the caller
feeds it from an unset vars.X, and GitHub accepts that as provided. That
produced a malformed download URL and an opaque aws CLI failure instead of a
clear error.
@TheMeinerLP
TheMeinerLP merged commit 03e0355 into main Aug 10, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant