ci: publish a rolling dev prerelease from main - #96
Merged
Conversation
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 mailboxes --experimental fetches releases/tags/dev, so without a workflow like this there is nothing for it to download. The build steps mirror release.yml deliberately. The publish step deletes and recreates the release because editing a published release does not move its tag to the new commit; a concurrency group keeps two runs from overlapping on that delete-and-recreate, and the JAR count is asserted because DPM installs the first .jar asset it finds. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of the rollout behind Dan's Plugin Manager's experimental release channel. DPM can now install main-branch builds with
/dpm get mailboxes --experimental, which readsreleases/tags/dev— but nothing in this organisation publishes such a release yet, so there is currently nothing for that command to download. This workflow publishes it.What it does
On every push to
mainthat touches something other than documentation, the JAR is rebuilt and republished as a prerelease taggeddev. Because it is marked as a prerelease, GitHub's "latest release" is unaffected and plugins on the stable channel see no change.Notes on the approach
release.ymldeliberately (Maven, same JDK, same artifact path). If the release build changes, this file has to change with it — a comment at the top says so.target_commitish. Recreating it with--target "$GITHUB_SHA"is what makesdev-<short sha>change from build to build; without it every build would look identical and DPM would report "already up to date" forever. Aconcurrencygroup prevents two runs overlapping on that delete-and-recreate, and queues rather than cancels, since a cancelled run could leave the repository with no dev release at all..jarasset it finds on the release, so a release carrying two JARs would leave the installed build depending on asset order. An empty or ambiguous glob match now fails the run instead.Verification
The same workflow was merged to Medieval-Factions first and confirmed end to end: the published release returned a 40-character commit sha in
target_commitish, DPM's parser turned it intodev-cc688da, the JAR downloaded anonymously over HTTP 200 with no token, andreleases/lateststill returned the real release rather than the prerelease.The first run of this workflow will be visible on
mainimmediately after merge.drafted by Claude on behalf of Daniel Stephenson