[workflow] static-site-pages-deploy

[HereLiesAz]

Capability name

static-site-pages-deploy

Purpose

Build a repository's static web/PWA output (e.g. a Kotlin/Wasm, plain JS, or any other static bundle) and publish it to GitHub Pages for that repository, so the result is reachable at a live URL. Generic across any repository that produces a static output directory — not specific to Compose Multiplatform or to any one repository. First consumer: HereLiesAz/MeatPiety, whose shared Kotlin Multiplatform module has a wasmJs target (Compose Multiplatform for Web) producing a static site via gradle :shared:wasmJsBrowserDistribution.

Repository-specific inputs/profile data

• target_repository
• build command (e.g. gradle :shared:wasmJsBrowserDistribution)
• build output directory to publish (e.g. shared/build/dist/wasmJs/productionExecutable)
• Java/Gradle/Node toolchain versions, if the build needs them
• Pages deployment method (gh-pages branch push vs. the GitHub Pages deployment API/actions/deploy-pages)
• custom domain, if any (CNAME), as optional profile data

Existing secrets to reuse

GH_TOKEN — GitHub API/release access (already cataloged); reused here to push the built site or call the Pages deployment API.

New secrets, if unavoidable

None.

Generalization checklist

• No target repository name is hard-coded.
• No package/application ID, branch, path, artifact name, or release name is hard-coded when it can be an input/profile value.
• I reviewed the existing secret catalog before requesting a new secret.
• Missing required secrets will fail explicitly with the secret name and purpose.

---

Filed from HereLiesAz/MeatPiety's .github/workflow-request.yml new_workflow_request entry, per this repo's centralized-workflow submission policy.