Fix stale Java release preparation

[devm33]

Summary

• check out the live main branch when preparing Java releases instead of the workflow dispatch SHA
• retry the documentation version commit from the latest remote commit when main advances
• record the documentation commit and rollback base only after the push succeeds, avoiding unsafe rollback attempts with empty identities

Root cause analysis

Actions run 33810120846 failed differently on its two attempts:

1. Attempt 1, September 3: the Java job checked out 39c027b0, pushed documentation commit 70fa5d31, and created Maven release commit d6791fcd. The Maven release plugin then failed when GitHub rejected the java/v1.0.13-preview.6 tag push with remote: fatal error in commit_refs. The guarded rollback succeeded and pushed 18fba144 and 81ffc2a7, reverting the release and documentation commits.
2. Attempt 2, September 4: rerunning the workflow retained the original run SHA, 39c027b0. The Java workflow used the default actions/checkout ref, so it checked out that old commit even though main had advanced through the rollback commits and Update @github/copilot to 1.0.83-4 #2507 to 184e504c. Its new documentation commit 3bdce0b6 was therefore rejected as a non-fast-forward push.
3. The documentation step wrote docs_commit_sha before the failed push, which triggered rollback. However, pre_prepare_commit was recorded by the following step, which never ran. The rollback received an empty base SHA and failed with Recorded pre-prepare commit does not exist.

Regression provenance

• The latent stale-checkout bug was introduced by Add java to monorepo: Phase 02: code and test CI. #1348 when the Java release workflow was added with a default event-SHA checkout followed by direct pushes to main. A rerun after any partial release rollback could therefore start from the original run SHA rather than current main.
• Unify publish.yml to include Java via workflow_call #1938 made the Java workflow reusable from the unified publish workflow but preserved the same checkout behavior; it exposed a broader path to the bug but did not introduce it.
• The secondary rollback failure was introduced by Java: add Windows x64 in-process runtime and native classifier publishing #2393, which moved guarded rollback into a separate job while recording pre_prepare_commit only after the documentation push.
• Update @github/copilot to 1.0.83-4 #2507 merely advanced main between attempts and exposed the stale checkout; it did not break Java.

The original attempt-1 GitHub tag rejection is separate from this workflow regression. This change makes release preparation and reruns safe after that or any similar partial failure.

Fix

• explicitly check out live main for release preparation
• rebuild and retry the documentation commit up to three times if main advances
• publish the final documentation commit and its parent as outputs only after the push succeeds

Validation

• cd java && ./scripts/test-update-documentation-versions.sh
• YAML parse check
• actionlint comparison against main (no new findings)

[Copilot]

Copilot review overview

🟡 Changes recommended

Retries can use a newer POM while retaining a stale automatically derived release version.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review tier: Balanced
Findings: 1

New issues introduced by this change (1)

Severity	Finding
	.github/​workflows/​java-publish-maven.yml — When releaseVersion is omitted, VERSION is derived from the POM before this loop. This reset…

What changed in this PR

Updates Java release preparation to operate safely against live main.

Changes:

• Checks out and retries against current main.
• Records rollback identities only after a successful documentation push.

File	Description
.github/​workflows/​java-publish-maven.yml	Adds live-branch checkout, retry logic, and safer rollback outputs.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.