Repository navigation
Publish the version the build job computed - #631
Merged
Merged
Conversation
Each publish job checked out again and recomputed the version from git. A tag added after the build job ran (createRelease on a release branch, or a rerun of a failed job after tagging) made a job publish a different version: an rc build's rerun could publish the bare release to GitHub Packages while the Maven Central job, gated on the build job's version, stayed skipped. GitVersion now returns DBOS_VERSION_OVERRIDE when it is set, and the publish jobs set it from the build job's version output. They no longer need the full history, so they check out at the default depth.
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
Both publishing jobs consistently use the build’s version, with no unresolved review findings.
No open issues 🎉
What changed in this PR
Ensures publishing uses the version computed by the build job, preventing later tags from changing the published version.
Changes:
- Adds a nonblank
DBOS_VERSION_OVERRIDEfallback ahead of Git-based version calculation. - Passes the build’s version to both publishing jobs and removes their full-history checkouts.
| File | Description |
|---|---|
build-logic/src/main/kotlin/dev/dbos/build/GitVersion.kt |
Uses the version override when provided. |
.github/workflows/publish.yml |
Propagates the build version to publishing jobs and uses shallow checkouts. |
Review effort: Balanced
kraftp
approved these changes
Oct 20, 2026
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
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.
Each job in the
Publishworkflow checks out again and recomputes the version from git. If a tag is added after thebuildjob has run, a later job publishes a different version from the onebuildcomputed. Two ways this happens:createRelease --pushon a release branch tags the commit while its run is in progress;Example: a push to
release/v1.3builds1.3.1-rc2, sobuildreports a prerelease andpublish-maven-centralis skipped. The commit is then tagged1.3.1. A rerun ofpublish-github-packagessees the tag and publishes1.3.1to GitHub Packages, while Maven Central never gets it.Changes
GitVersion.version()returnsDBOS_VERSION_OVERRIDEwhen it is set, and otherwise derives the version from git as before.publish-github-packagesandpublish-maven-centralsetDBOS_VERSION_OVERRIDEfromneeds.build.outputs.version. They no longer compute the version, so they check out at the default depth instead of the full history.buildstill uses the full history.I checked this in a depth-1 clone: with
DBOS_VERSION_OVERRIDE=1.3.1, the build producestransact-1.3.1.jarwithImplementation-Version: 1.3.1and the correctSCM-Revision.🤖 Generated with Claude Code