chore(java): publish pipeline hardening#363
Conversation
Javadoc and MR-jar/native layout previously first exercised during the live publish.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughUpdates Java SDK release tooling: adds a Cargo release profile with strip/thin-LTO, excludes native/dashboard assets from sourcesJar, expands the publish workflow's dry-run to build and verify multi-release JAR layout and native binaries, and revises README/action descriptions to reflect a Java 17 baseline. ChangesRelease Packaging and Publish Verification
Estimated code review effort: 2 (Simple) | ~15 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/publish-java.yml:
- Around line 153-158: The dry-run step in the publish workflow references a
task name that does not exist in the Java build, so update the Assemble publish
artifacts step to use the actual javadoc jar task exposed by the sdks/java
Gradle build, or register plainJavadocJar in sdks/java/build.gradle.kts if that
is the intended task name. Make sure the workflow command aligns with the task
defined by the Java build scripts so the dry-run can complete successfully.
In `@sdks/java/README.md`:
- Around line 17-31: The Java README install snippets are advertising a version
that is not ready to be published yet. Update the version shown in the Gradle
and Maven examples in the README to match the currently released artifact, and
keep it aligned with the version constants or release state used elsewhere in
the Java docs so the install instructions do not reference a future release.
- Around line 33-36: The README’s companion-artifacts section mentions
`taskito-processor`, but only in Gradle terms, so Maven users still lack a
usable compile-time setup example. Update the `taskito-processor` documentation
in this section to include a copy-pasteable Maven configuration for the
processor alongside the existing `TaskHandler` binding explanation, and keep the
references to `org.byteveda:taskito-processor`, `taskito-test`, and
`taskito-spring` consistent with the current docs.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 51f0d9c8-7525-4173-b9cf-47c01c44ece7
📒 Files selected for processing (5)
.github/actions/setup-java/action.yml.github/workflows/publish-java.ymlCargo.tomlsdks/java/README.mdsdks/java/build.gradle.kts
Release-prep items from the Java SDK audit (all but the version bump).
[profile.release]now setsstrip = true,lto = "thin"; the five bundled cdylibs shrink accordingly.Multi-Release: truemanifest, FFM overlay underMETA-INF/versions/22, all five platform natives present, and no binaries in the sources jar.setup-javaaction description now reflects the JDK 25 publish build../gradlew buildgreen with the new release profile.Remaining before tagging: version bump to 0.19.0, Central Portal namespace check for
org.byteveda, and oneworkflow_dispatchdry-run ofpublish-java.yml.Summary by CodeRabbit
Documentation
Bug Fixes
Build & Release