Wire Gradle Plugin Portal publishing for clean 1.0.0 release#230
Merged
Conversation
) Apply com.gradle.plugin-publish so the two java-gradle-plugin marker artifacts (incl. the second groupId) are hosted on the Gradle Plugin Portal via publishPlugins. Disable the marker -> Maven Central tasks so the Central listing carries only the clean featured-gradle-plugin impl jar (+ sources/javadoc/pom). Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Review Summary by QodoConfigure Gradle Plugin Portal publishing for 1.0.0 release
WalkthroughsDescription• Configure Gradle Plugin Portal publishing for plugin markers • Disable marker artifacts from Maven Central to keep listing clean • Add plugin metadata (display name, description, tags, website) • Add CI step to publish plugins on tagged releases only Diagramflowchart LR
A["Gradle Plugin Portal<br/>Plugin Publish Plugin"] -->|"publishPlugins task"| B["Plugin Markers<br/>+ Implementation JAR"]
C["Maven Central<br/>Maven Publish Plugin"] -->|"Filtered tasks"| D["Implementation JAR<br/>Only"]
E["CI Workflow<br/>publish.yml"] -->|"Tag-only step"| A
E -->|"Existing step"| C
File Changes1. featured-gradle-plugin/build.gradle.kts
|
Code Review by Qodo
Context used 1. Portal creds not passed
|
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
Pull request overview
This PR wires Gradle Plugin Portal publishing into the main release pipeline so the dev.androidbroadcast.featured Gradle plugin (and its marker artifacts) are published correctly for the 1.0.0 release, while keeping Maven Central “clean” (impl artifact only).
Changes:
- Add the
com.gradle.plugin-publishplugin to the version catalog. - Configure
featured-gradle-pluginwith Plugin Portal metadata and disable only the marker → Maven Central publish tasks. - Update the release workflow to run
:featured-gradle-plugin:publishPluginson tag builds using Plugin Portal credentials.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
gradle/libs.versions.toml |
Adds the Plugin Publish plugin version and alias to the version catalog. |
featured-gradle-plugin/build.gradle.kts |
Applies com.gradle.plugin-publish, sets Portal metadata, and disables marker publishing to Maven Central. |
.github/workflows/publish.yml |
Adds a tag-only CI step to publish the plugin to the Gradle Plugin Portal. |
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
Comment on lines
+59
to
+63
| env: | ||
| GRADLE_PUBLISH_KEY: ${{ secrets.GRADLE_PUBLISH_KEY }} | ||
| GRADLE_PUBLISH_SECRET: ${{ secrets.GRADLE_PUBLISH_SECRET }} | ||
| ORG_GRADLE_PROJECT_VERSION_NAME: ${{ steps.version.outputs.VERSION_NAME }} | ||
| run: ./gradlew --no-daemon :featured-gradle-plugin:publishPlugins --no-configuration-cache |
There was a problem hiding this comment.
1. Portal creds not passed 🐞 Bug ☼ Reliability
The new Plugin Portal publish step sets GRADLE_PUBLISH_KEY/SECRET as environment variables but does not pass them into Gradle as project/system properties and there is no repo build logic that maps these env vars into Gradle properties. As a result, the Gradle build won’t reliably receive publish credentials and the portal publish can fail due to missing auth.
Agent Prompt
## Issue description
The workflow exports `GRADLE_PUBLISH_KEY` / `GRADLE_PUBLISH_SECRET` but does not pass them to Gradle as properties (the way other publishing creds are provided via `ORG_GRADLE_PROJECT_*`). There is also no composite action/build script that maps these env vars to Gradle properties, so `:featured-gradle-plugin:publishPlugins` can run without credentials.
## Issue Context
- Maven Central step uses `ORG_GRADLE_PROJECT_*` env vars, which Gradle automatically maps to project properties.
- Plugin Portal step currently only sets plain env vars.
## Fix Focus Areas
- .github/workflows/publish.yml[55-63]
## Suggested change
Update the step to pass the secrets explicitly to Gradle, e.g.
```yaml
- name: Publish plugin to Gradle Plugin Portal
if: startsWith(github.ref, 'refs/tags/')
env:
ORG_GRADLE_PROJECT_VERSION_NAME: ${{ steps.version.outputs.VERSION_NAME }}
run: |
./gradlew --no-daemon :featured-gradle-plugin:publishPlugins --no-configuration-cache \
-Pgradle.publish.key='${{ secrets.GRADLE_PUBLISH_KEY }}' \
-Pgradle.publish.secret='${{ secrets.GRADLE_PUBLISH_SECRET }}'
```
(Alternatively, write them to `~/.gradle/gradle.properties` in the job, but passing `-P` is simplest/explicit.)
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Comment on lines
+62
to
+63
| ORG_GRADLE_PROJECT_VERSION_NAME: ${{ steps.version.outputs.VERSION_NAME }} | ||
| run: ./gradlew --no-daemon :featured-gradle-plugin:publishPlugins --no-configuration-cache |
There was a problem hiding this comment.
2. Version_name override ignored 🐞 Bug ≡ Correctness
The workflow computes a tag/SNAPSHOT VERSION_NAME and exports it as ORG_GRADLE_PROJECT_VERSION_NAME, but the featured-gradle-plugin included build force-sets its version from ../gradle.properties, overriding CI-provided VERSION_NAME. This can publish the plugin with the gradle.properties version instead of the computed tag/SNAPSHOT version, creating wrong-version releases and inconsistent artifacts.
Agent Prompt
## Issue description
`featured-gradle-plugin/settings.gradle.kts` currently sets `project.version` from `../gradle.properties` unconditionally in `gradle.beforeProject { ... }`, which overrides `VERSION_NAME` provided via CI (`ORG_GRADLE_PROJECT_VERSION_NAME`). This defeats the workflow’s computed version for the included build.
## Issue Context
- CI computes `VERSION_NAME` from the tag name (or appends `-SNAPSHOT` on branch pushes).
- The included build hard-pins the version from `../gradle.properties` (`VERSION_NAME=1.0.0`), so CI overrides are ignored.
## Fix Focus Areas
- featured-gradle-plugin/settings.gradle.kts[38-58]
- gradle.properties[38-40]
- .github/workflows/publish.yml[30-63]
## Suggested change
In `featured-gradle-plugin/settings.gradle.kts`, resolve the version by preferring a Gradle property override, falling back to `../gradle.properties`:
```kotlin
gradle.beforeProject {
val parentProps = Properties().apply {
parentPropertiesText.orNull?.reader()?.use { load(it) }
}
// Prefer CI / command-line overrides
val overriddenVersion = providers.gradleProperty("VERSION_NAME").orNull
val fileVersion = parentProps.getProperty("VERSION_NAME")
val resolvedVersion = overriddenVersion ?: fileVersion ?: "unspecified"
// Don’t clobber existing overrides
parentProps.forEach { key, value ->
if (!extensions.extraProperties.has(key.toString())) {
extensions.extraProperties[key.toString()] = value.toString()
}
}
extensions.extraProperties["VERSION_NAME"] = resolvedVersion
version = resolvedVersion
}
```
This keeps `gradle.properties` as the default source of truth while allowing CI/tag/SNAPSHOT overrides to actually take effect for the included build.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
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.
Purpose
Bring the clean Gradle Plugin Portal publishing into the
mainrelease line so the 1.0.0 release publishes correctly:dev.androidbroadcast.featured:featured-gradle-plugin.publish.ymlgains a tag-only:featured-gradle-plugin:publishPluginsstep so a tagged release actually lands the plugin (and its markers) on the Plugin Portal. Without it, removing markers from Central would makeplugins { id(...) }unresolvable.VERSION_NAMEstays1.0.0(no SNAPSHOT bump pulled in). Closes #229.After merge (release procedure)
v1.0.0on the mergedmainHEAD (the existing tag predates these changes) and push → triggerspublish.yml:publishPluginsuploads directly (live; subject to first-time namespace approval fordev.androidbroadcast).plugins { id("dev.androidbroadcast.featured") version "1.0.0" }resolves via the defaultgradlePluginPortal(), and the Central listing shows a singlefeatured-gradle-pluginartifact (no*.gradle.pluginmarkers).Portal credentials
GRADLE_PUBLISH_KEY/GRADLE_PUBLISH_SECRETare present in theMainenvironment.🤖 Generated with Claude Code