diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 0fd5705dc..e9502859e 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -81,13 +81,16 @@ jobs: git config user.name "github-actions[bot]" git config user.email "41898282+github-actions[bot]@users.noreply.github.com" - - name: release:prepare (poms only; commits + tag vX; pushes to master) + - name: release:prepare (build+install, commits + tag vX; pushes to master) + # preparationGoals=clean install (in pom.xml): the modules cross-depend on core's test-jar, + # which only exists after core is packaged+installed, so a poms-only "validate" prepare cannot + # resolve it. -DskipTests keeps it fast; the "refuse red master" guard already gated on tests. run: | ./mvnw --batch-mode release:prepare \ -DreleaseVersion=${{ inputs.releaseVersion }} \ -DdevelopmentVersion=${{ inputs.developmentVersion }} \ -DdryRun=${{ inputs.dryRun }} \ - -Dlicense.skip -Darguments="-Dlicense.skip" + -Dlicense.skip -Darguments="-Dlicense.skip -DskipTests" - name: Deploy the release tag to Maven Central if: ${{ !inputs.dryRun }} diff --git a/README.adoc b/README.adoc index e9d504c29..4c2b9b21b 100644 --- a/README.adoc +++ b/README.adoc @@ -1382,7 +1382,7 @@ Releases use `maven-release-plugin` and are *tag-as-truth*: `release:prepare` ta To cut a release: . Run the *Release* workflow (Actions tab), supplying the release version (e.g. `0.6.0.0`) and the next development version (e.g. `0.6.0.1-SNAPSHOT`). Tick *Dry run* first to rehearse with no side effects. -. It runs `release:prepare` (poms only, no build; tags `v` and pushes the two version commits to `master`), then checks out that tag and deploys it to Maven Central via `.github/workflows/release.yml`, then creates a GitHub release. `master` returns to the next `-SNAPSHOT` automatically. +. It runs `release:prepare` (builds+installs the reactor to validate the release compiles, then tags `v` and pushes the two version commits to `master`), then checks out that tag and deploys it to Maven Central via `.github/workflows/release.yml`, then creates a GitHub release. `master` returns to the next `-SNAPSHOT` automatically. Required GitHub repository secrets: diff --git a/docs/plans/2026-07-28-release-pipeline-hardening.md b/docs/plans/2026-07-28-release-pipeline-hardening.md index 3739ecea6..7ca25fd10 100644 --- a/docs/plans/2026-07-28-release-pipeline-hardening.md +++ b/docs/plans/2026-07-28-release-pipeline-hardening.md @@ -95,6 +95,17 @@ deliberate human gate. If PR review of the release itself is a hard requirement, (release-please)** is the robust PR-native choice; **Option 2 is not recommended** — it reintroduces the merge-strategy fragility we're trying to eliminate. +## Correction (post dry-run, 2026-07-28) + +The first dry run failed at `release:prepare` phase 10/17 (`run-preparation-goals`): `preparationGoals=validate` +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 a poms-only +`validate` prepare tries Central and 404s. Fix: **`preparationGoals=clean install`** with `-DskipTests` (passed +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) but skips 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. The dry run did its job: it caught this with zero side effects. + ## Detailed design (Option 1) **`.github/workflows/release.yml`** — `workflow_dispatch` (inputs: `releaseVersion`, `developmentVersion`): diff --git a/pom.xml b/pom.xml index 52df41aee..6ed7313bc 100644 --- a/pom.xml +++ b/pom.xml @@ -599,10 +599,20 @@ release:prepare rewrites the poms, makes the two release commits ("prepare release vX" + "prepare for next development iteration"), tags vX, and PUSHES them to master (pushChanges=true) using a repo-admin PAT that - bypasses the master ruleset's pull_request requirement. preparationGoals=validate - keeps prepare pom-only (no build); release.yml then checks out the exact tag vX - and deploys it. The tag is the single source of truth - nothing scans history. --> - validate + bypasses the master ruleset's pull_request requirement. release.yml then checks + out the exact tag vX and deploys it. The tag is the single source of truth - + nothing scans history. + + preparationGoals=clean install (not the "poms only" validate we first tried): + the modules cross-depend on parallel-consumer-core's test-jar + (bz.stub.parallelconsumer:parallel-consumer-core:jar:tests), which does not exist + until core is packaged+installed. A validate-only prepare therefore fails to + resolve it (tries Central, 404). "clean install" builds+installs the reactor so + the test-jars are present, cross-module deps resolve, and the release-versioned + poms are proven to compile before the tag is cut. -DskipTests (passed via + release.yml's -Darguments) keeps prepare fast - the "refuse red master" guard + already gates on a green test run. --> + clean install true diff --git a/src/docs/README_TEMPLATE.adoc b/src/docs/README_TEMPLATE.adoc index 419971d70..c8746a79c 100644 --- a/src/docs/README_TEMPLATE.adoc +++ b/src/docs/README_TEMPLATE.adoc @@ -1133,7 +1133,7 @@ Releases use `maven-release-plugin` and are *tag-as-truth*: `release:prepare` ta To cut a release: . Run the *Release* workflow (Actions tab), supplying the release version (e.g. `0.6.0.0`) and the next development version (e.g. `0.6.0.1-SNAPSHOT`). Tick *Dry run* first to rehearse with no side effects. -. It runs `release:prepare` (poms only, no build; tags `v` and pushes the two version commits to `master`), then checks out that tag and deploys it to Maven Central via `.github/workflows/release.yml`, then creates a GitHub release. `master` returns to the next `-SNAPSHOT` automatically. +. It runs `release:prepare` (builds+installs the reactor to validate the release compiles, then tags `v` and pushes the two version commits to `master`), then checks out that tag and deploys it to Maven Central via `.github/workflows/release.yml`, then creates a GitHub release. `master` returns to the next `-SNAPSHOT` automatically. Required GitHub repository secrets: