Repository navigation
fix(release): build+install in release:prepare so cross-module test-jars resolve - #64
Conversation
…ars resolve
The dry run of the Release workflow failed at release:prepare phase 10/17
(run-preparation-goals): preparationGoals=validate ("poms only, no build")
could not resolve bz.stub.parallelconsumer:parallel-consumer-core:jar:tests.
The vertx/reactor/mutiny modules depend on core's test-jar, which does not
exist until core is packaged+installed, so validate tried Central and 404'd.
Change preparationGoals validate -> clean install and pass -DskipTests via
release.yml's -Darguments. Prepare now builds+installs the reactor (producing
the test-jars, resolving cross-module deps, and proving the release-versioned
poms compile) while skipping test execution - the "refuse red master" guard
already gates on a green test run.
Validated locally: clean install -DskipTests -Dlicense.skip -> BUILD SUCCESS,
all 11 modules build, zero test-jar resolution errors.
Docs (README, README template, hardening plan) corrected: "poms only, no
build in prepare" was not achievable given the inter-module test-jar dep.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T6Biwo4QXfD9CFrZnCq1zw
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
❌ Duplicate Code ReportTwo engines run in parallel for cross-validation. Each has its own thresholds tuned to its baseline - the real safety net is the per-engine "max increase vs base" check. ✅ PMD CPD
No new clones introduced by this PR. ❌ jscpd (language-agnostic)
No new clones introduced by this PR. Powered by astubbs/duplicate-code-cross-check |
✅ SpotBugs ReportNo bugs found (new bugs only — baseline from base branch excluded). |
|
@claude review please |
|
Claude finished @astubbs's task in 1m 54s —— View job Review complete ✅
SummaryThis is a well-diagnosed, minimal fix. I traced through the mechanics and the change is correct: Root cause is real and correctly identified.
No GPG/signing side effects. Docs are consistent. README.adoc, Minor, non-blocking observations
No bugs or correctness issues found. This looks safe to merge. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #64 +/- ##
============================================
- Coverage 77.11% 77.08% -0.03%
- Complexity 75 1152 +1077
============================================
Files 82 82
Lines 4190 4190
Branches 386 386
============================================
- Hits 3231 3230 -1
Misses 767 767
- Partials 192 193 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
❌ Mutation Testing (PIT) ReportPIT did not produce a report. Most commonly this means a test failed in the baseline (PIT runs all tests unmodified first to establish green) and PIT aborted before mutating. See the "Run PIT mutation testing" step logs for the failing test, then either fix it or add it to |
What
The Release workflow's dry run (#62) failed at
release:preparephase 10/17 (run-preparation-goals).preparationGoals=validate("poms only, no build") could not resolvebz.stub.parallelconsumer:parallel-consumer-core:jar:tests- the vertx/reactor/mutiny modules depend on core's test-jar, which doesn't exist until core is packaged+installed, sovalidatetried Central → 404 →BUILD FAILURE.The dry run did exactly its job: it caught this with zero side effects (dry-run mode = no commits/tags/deploy).
Fix
pom.xml:preparationGoalsvalidate→clean install.github/workflows/release.yml:-Darguments="-Dlicense.skip -DskipTests"preparenow builds+installs the reactor (producing the test-jars, resolving cross-module deps, and proving the release-versioned poms compile) while skipping test execution - the "refuse red master" guard already gates on a green test run. "Poms only, no build in prepare" was not achievable given the inter-module test-jar dependency; docs (README, template, hardening plan) corrected accordingly.Validation
./mvnw clean install -DskipTests -Dlicense.skip→ BUILD SUCCESS, all 11 modules build, zero test-jar resolution errors.Follow-up (not this PR)
The local build log showed the
@StandardException"constructor cannot be applied" flaky-race interleaved but still finished green. Now thatpreparecompiles, a release run can intermittently flake there and need a re-run - tracked in #60 /docs/inflight.md. Hardening those exception constructors remains the real fix for reliable releases.🤖 Generated with Claude Code
https://claude.ai/code/session_01T6Biwo4QXfD9CFrZnCq1zw