Skip to content

ci: publish a rolling dev prerelease from main - #89

Merged
dmccoystephenson merged 1 commit into
mainfrom
feat/dev-release-workflow
Aug 10, 2026
Merged

ci: publish a rolling dev prerelease from main#89
dmccoystephenson merged 1 commit into
mainfrom
feat/dev-release-workflow

Conversation

@dmccoystephenson

Copy link
Copy Markdown
Member

Part of the rollout behind Dan's Plugin Manager's experimental release channel. DPM can install main-branch builds with /dpm get activitytracker --experimental, which reads releases/tags/dev — this workflow publishes that release.

Note on this repository specifically

Unlike the other plugins in this rollout, this repository has no release.yml whose build steps could be mirrored. The build was therefore run locally first, and mvn clean package was confirmed to succeed and leave exactly one publishable JAR in target/ (the shade plugin's original-*.jar is excluded, as it is elsewhere in the organisation). The JDK is set to 8 to match the existing CI workflow.

What it does

On every push to main that touches something other than documentation, the JAR is rebuilt and republished as a prerelease tagged dev. Because it is marked as a prerelease, GitHub's "latest release" is unaffected.

  • The release is deleted and recreated rather than edited. Editing a published release does not move its tag to the new commit, and DPM derives each build's version identity from target_commitish. Recreating with --target "$GITHUB_SHA" is what makes dev-<short sha> change between builds; without it every build would look identical and DPM would report "already up to date" forever.
  • Exactly one JAR is asserted before publishing, because DPM installs the first .jar asset it finds and two JARs would make the installed build depend on asset order.
  • Documentation-only merges are skipped, and forks are excluded by a repository guard.

Verification

The same workflow is already merged and confirmed working end to end on Medieval-Factions, AlternateAccountFinder, Currencies, FoodSpoilage, Herald and Dans-Essentials: each published release returns a 40-character commit sha in target_commitish, DPM's parser turns it into dev-<short sha>, the JAR downloads anonymously over HTTP 200, and releases/latest still returns the real release.

No CHANGELOG entry is included because this repository does not keep a CHANGELOG.md.


drafted by Claude on behalf of Daniel Stephenson

Adds dev-release.yml, which rebuilds the JAR on every non-documentation push
to main and republishes it as the `dev` prerelease.

This is what Dan's Plugin Manager's experimental release channel reads:
/dpm get activitytracker --experimental fetches releases/tags/dev, so without a
workflow like this there is nothing for it to download.

This repository has no release.yml to mirror, so the build was run locally
first to confirm that mvn clean package succeeds and leaves exactly one
publishable JAR in target/. The JDK matches the one the existing CI workflow
uses. The publish step deletes and recreates the release because editing a
published release does not move its tag to the new commit.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@dmccoystephenson
dmccoystephenson merged commit ecc879d into main Aug 10, 2026
3 checks passed
@dmccoystephenson
dmccoystephenson deleted the feat/dev-release-workflow branch August 10, 2026 01:40
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