Release Automation
Creating a GitHub Release triggers a workflow that builds the plugin and attaches the jar, so every release has a reproducible artifact.
Every DPC plugin should build and attach its own jar when a release is created. The convention specifies the workflow file down to the steps.
The workflow
.github/workflows/release.yml, triggered on: release: types: [created], with permissions: contents: write. It checks out, sets up JDK 17 (Temurin), makes gradlew executable, runs ./gradlew clean build, and uploads build/libs/*.jar to the release.
Why drafts matter
The trigger fires on release creation, including drafts. That is deliberate: a maintainer can create a draft release, let CI build and attach the jar, and hand that artifact to users as an experimental build before deciding to publish. Testing a release candidate needs no separate pipeline.
Why it is a convention and not a nicety
Manual jar uploads fail in two ways that automation removes. They can be forgotten — leaving a release with notes and no download. And they can be built from a dirty working tree, so the published jar does not correspond to the tag. Building in CI from a clean checkout makes the artifact a function of the commit.
There is also a consumer that depends on it: Dan's Plugin Manager installs plugins by reading GitHub releases. A release without an attached jar is a release DPM cannot install.
The flagship deviates, for a reason
Medieval Factions follows the template but inserts a step before the build: it clones Ponder at tag 2.0.0 and runs publishToMavenLocal. The library version it needs is not resolvable from a public repository at build time, so CI builds it from source first.
That is worth knowing before copying the convention's workflow verbatim into a plugin that depends on Ponder — the template alone will not resolve the dependency.
The other half
This convention covers releases a maintainer cuts deliberately. Repositories also publish a rolling dev prerelease on every merge to main, which is what the experimental Release Channel serves — the same automation, on a trigger that fires continuously rather than on a human decision.
Related
Testing and CI covers the build and test side. Both live in DPC Conventions.