Fix Maven Central publishing: invalid version from unoverridable GITHUB_REF#10
Merged
Conversation
The auto-release inline publish tried to override GITHUB_REF via step env, but GitHub Actions re-applies default variables, so Gradle resolved the version to 'refs/heads/master' and every publish since v150.0.7869.0 failed with "version cannot contain '/'" — tags v150.0.7869.0 through v152.0.7934.0 exist but were never published to Maven Central. Pass -PpublishVersion explicitly instead, and harden the fallback so non-tag refs resolve to the dev version rather than an invalid string.
Tags pushed with GITHUB_TOKEN don't trigger other workflows, so release-graalvm.yaml never fired for nightly bumps and no GitHub release was created. Create it explicitly in the auto-release run.
Collaborator
Author
|
Added a second commit: the auto-release workflow now also creates the GitHub release explicitly — tags pushed with |
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.
Context
gradle/libs.versions.tomlis already pinned to the latest upstream PDFium (chromium/7934/ 152.0.7934.0) — the nightly auto-release bumped it on July 7. But nothing after 150.0.7857.0 ever reached Maven Central: tagsv150.0.7869.0→v152.0.7934.0exist, master was fast-forwarded, yet Central still serves 150.0.7857.0 as latest.Root cause
The auto-release
publishjob setsGITHUB_REF: refs/tags/v…in the stepenv:to drivepublishVersioninpdfium/build.gradle.kts. GitHub Actions re-applies default variables after userenv:, so the override never takes effect: Gradle seesrefs/heads/master(schedule event),removePrefix("refs/tags/v")is a no-op, and publishing fails with:(see run 28847340961, July 7). The tag is pushed before the publish step, so every failed run still leaves a release tag behind — which the guard then refuses to reuse.
Fix
pdfium/build.gradle.kts:-PpublishVersiongradle property takes precedence; theGITHUB_REFfallback now only accepts actualrefs/tags/v*refs instead of silently producing an invalid version.pdfium-auto-release.yaml: pass-PpublishVersion=<full_version>to the publish invocation instead of the ineffectiveGITHUB_REFenv override.152.0.7934.0b(the next release, see below).The tag-push path (
publish-maven.yaml) is unaffected — thereGITHUB_REFgenuinely is the tag ref.Release plan
v152.0.7934.0already exists as a git tag (from the failed July 7 run), so per the established convention the recovery release isv152.0.7934.0b, tagged on master after this merge. It ships PDFium 152.0.7934.0 plus the clickable-links feature from #9, andpublish-maven.yamlrebuilds all JNI natives (including macOS/Windows) as part of the run.Test plan
0.1.0,-PpublishVersion=152.0.7934.0b→152.0.7934.0b,GITHUB_REF=refs/tags/v152.0.7934.0b→152.0.7934.0b,GITHUB_REF=refs/heads/master→0.1.0(previouslyrefs/heads/master)v152.0.7934.0btag push publishes to Maven Central via CI