fix: stop publishing artefacts named "0.2.x # x-release-please-version" - #27
Merged
Conversation
Java .properties has no trailing-comment syntax, so version=1.0.0 # x-release-please-version sets the version to that entire string. Gradle resolved it verbatim, named the jar after it, and published it that way. Every Maven release so far carries the marker in its version. The npm package was unaffected, because package.json is JSON. The marker now brackets the line using release-please's start/end block form, which leaves the property value clean. Two checks were complicit and are fixed too. The release workflow read the version with sed taking everything up to the first space, so it saw a clean "0.2.6" and passed -- a check written in exactly the way that hides this. Both it and a new CI gate now ask Gradle for the version it actually resolved, and the gate additionally asserts both packages carry a bare semver string and agree with each other. It was verified failing against the corrupt value before being committed.
ExtraToast
force-pushed
the
fix/corrupt-gradle-version
branch
from
September 2, 2026 21:52
dae7103 to
e573e14
Compare
Merged
github-actions Bot
added a commit
that referenced
this pull request
Sep 2, 2026
🤖 I have created a release *beep* *boop* --- <details><summary>1.0.1</summary> ## [1.0.1](v1.0.0...v1.0.1) (2026-09-02) ### Bug Fixes * **ci:** repair CodeQL and read the version from a ref that may predate the task ([#29](#29)) ([5bbbdf4](5bbbdf4)) * stop publishing artefacts named "0.2.x # x-release-please-version" ([#27](#27)) ([b01cad2](b01cad2)) </details> --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.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.
What shipped
Every Maven release so far is published with the release-please marker inside its version:
Java
.propertieshas no trailing-comment syntax, soversion=0.2.6 # x-release-please-versionsets the version to that whole string. Gradle resolved it verbatim and named the jar after it. The npm package was unaffected —package.jsonis JSON.The fix
The marker now brackets the line using release-please's
x-release-please-start-version/x-release-please-endblock form, leaving the property value clean.The checks were complicit
The release workflow read the version with
sed 's/^version=\([^ ]*\).*/\1/p'— everything up to the first space — so it saw a clean0.2.6and passed. Both that check and a new CI gate now ask Gradle for the version it resolved instead of re-parsing the file, and the gate asserts both packages carry a bare semver string and agree with each other. It was verified to fail against the corrupt value before being committed.