perf(ci): publish releases from the build's artifacts instead of recompiling (#37607)

[wezell]

Part B of 2, depends on #37617 (Part A). Base is Part A's branch so the diff below is only Part B's; retarget to main once Part A merges.

Refs #37607.

Part A adds the inputs with no-op defaults. This flips them on for the two release workflows:

generate-test-image: false
generate-build-classes: false
release-build: true
reuse-build-artifacts: true        # cicd_7 reads this from a dispatch input
docker-cache-scope-prefix: release

4 files, +112/−5, 1 commit.

Why this is a separate PR

It cannot be validated without an actual release. release-prepare commits and pushes a release branch and creates the GitHub release (cicd_comp_release-prepare-phase.yml:347-348), so there is no dry run of cicd_6. Splitting means Part A can land on review + green CI while this half waits for a deliberately chosen release.

The section-7 test assertions for these flags moved here with them — asserting a flag is set is only meaningful next to the change that sets it.

Two hardening items the review surfaced

1. cicd_7 escape hatch. reuse-build-artifacts: true was hardcoded, so the only way back to rebuild-then-publish was editing the workflow. That matters concretely: releasing a tag cut before release-build existed runs the tag's own maven-job (composite actions resolve from the checked-out ref, and cicd_comp_build-phase.yml checks out ref: release_tag before uses: ./.github/actions/core-cicd/maven-job). That action has no release-build input, so it installs unsuffixed coordinates, while the new release phase expects suffixed ones and blocks the publish. It is now a workflow_dispatch input defaulting to true, so false is a supported fallback.

cicd_6 deliberately does not get an input: it creates its tag from main during the run, so its build phase is always current. It also already declares 11 workflow_dispatch inputs against a documented maximum of 10 — adding a twelfth would make that pre-existing problem worse. (See Part A's notes.)

2. An earlier coordinate tripwire. This is the more interesting one. The order is:

PR Build   →  produces maven-repo + docker-build-context
deployment →  pushes Docker images
release    →  validates coordinates, publishes Maven

So Validate Release Artifacts fails closed for the Maven publish but runs after deployment has already pushed images. A build that produced the wrong coordinates would ship images and only then block. "Validation gates the irreversible step" is only half true.

The build job has no such split — nothing is pushed from there — so it now asserts the exact expected <revision>[-<suffix>] coordinate (dotcms-core-<version>.pom and .jar) is present in ~/.m2/repository, gated on release-build == true. Reading the version from .mvn/maven.config's -Drevision= rather than re-deriving it, so a mismatch between what the release branch pins and what the build installed fails here instead of after images are out.

Still needed before merge

• The validation run. Watch it expecting the Maven publish to fail closed on bad coordinates. Residual risk after the tripwire is much smaller, but not zero — the tripwire covers dotcms-core, not every module publish.sh uploads.
• Not fixed here: cicd_7 can overwrite the primary release if both java_version and RELEASE_JAVA_VARIANT_VERSION resolve empty (pre-existing; wants a guard in extract-version). Kept out to hold this diff small and reviewable.
• Needs a real-run check: a variant image's MANIFEST Implementation-Version / OSGi versions become <version>-java-25. ReleaseInfo.getVersion() is read by AutoUpdaterAjax, SdkVersionWebInterceptor, MetricsConfig and HealthStateManager.

Checks

Test suites — 90 assertions across both suites, green. actionlint — clean. The new assertions cover the tripwire's gate and that it matches the exact primary artifact, and that cicd_7 reads the input rather than hardcoding it.

[claude]

Claude finished @wezell's task in 2m 57s —— View job

---

Review: perf(ci) publish releases from build artifacts (Part B)

• Read the diff against origin/main
• Trace the coordinate tripwire against maven-job suffix/changelist logic
• Trace the cicd_7 escape hatch end-to-end
• Post review

---

New Issues

• 🟠 High: .github/workflows/cicd_7-release-java-variant.yml:134 — The reuse-build-artifacts escape hatch cannot achieve its documented purpose, because it only reaches the release job while the build job hardcodes release-build: true.

  Walk the stated scenario (releasing a tag cut before release-build existed, dispatched from main):

  • cicd_comp_build-phase.yml is resolved at the caller's dispatch ref (main), so the new tripwire "Verify release coordinates were installed" (cicd_comp_build-phase.yml:202-229, gated if: inputs.release-build == true) is present and active.
  • release-build: true is hardcoded here (cicd_7:134) regardless of reuse-build-artifacts, so the tripwire's gate is always satisfied for this workflow.
  • The maven-job composite is resolved from the checked-out tag (ref: ${{ needs.extract-version.outputs.tag }}), and that old action has no release-build input → no -Dchangelist=-java-NN (maven-job/action.yml:397-412) → it installs unsuffixed dotcms-core-<revision> coordinates.
  • The tripwire computes the expected version as <revision>-<suffix> (cicd_comp_build-phase.yml:218-224) and looks for dotcms-core-<revision>-java-NN.{pom,jar}, which the old maven-job never installed → the build job fails before the release phase's rebuild-then-publish fallback is ever reached.

  So setting reuse-build-artifacts: false — the one knob offered to recover this exact case — does not disable release-build in the build job, and the tripwire blocks the run anyway. The failure is fail-closed (it blocks rather than ships bad artifacts), so it is not a correctness/data risk, but it means the escape hatch added in this PR is non-functional for its stated use.

  Suggested fix: couple the build job's release-build to the same input, so the two phases agree:

  release-build: ${{ inputs.reuse-build-artifacts }}

  With reuse-build-artifacts: false this turns off the changelist/suffixing and the tripwire gate, leaving the release phase to rebuild-then-publish as intended. Fix this →

---

Everything else checks out:

• The tripwire's version math is correct for both consumers: primary (cicd_6, empty suffix → version = revision) and variant (<revision>-java-25), matching maven-job's -Dchangelist=${suffix} output (maven-job/action.yml:412). It reads SUFFIX from the build's resolved raw_suffix output rather than re-deriving — consistent with the single-source-of-suffix goal.
• set -uo pipefail without -e is correct here: a failed awk yields an empty revision caught by the -z guard; SUFFIX is always defined (possibly empty) via the env: block, safe under -u.
• release-build is a boolean input (cicd_comp_build-phase.yml:74-78), so if: inputs.release-build == true is a real boolean comparison (not the string-vs-boolean coercion trap).
• cicd_6 correctly omits the escape hatch — it cuts its tag from main during the run, so its build phase is always the current code.

No security, SQL, or secret-handling concerns in this diff.
· branch issue-37607b-release-optin-validated