Problem
With #156 and #158 fixed, the tag-driven deploy now authenticates, uploads and publishes successfully. However a deployment of a version whose artifacts are already live on Maven Central fails validation ("Component with package url ... already exists"), which turns the release job red, skips the Docker publish and the automated PR back to main. This exact case occurred on release/2026.08.30: an earlier run's deployment published the artifacts server-side before its client crashed, so the fully-fixed re-run correctly refused to double-publish and the job went red even though the release is live.
Fix
Wrap the deploy step with an idempotency guard: if mvn deploy fails, check whether the parent and core POMs of the tagged version are already served from repo1.maven.org; if they are, log that the version is already live and exit 0 so the release completes (Docker publish + back-to-main PR). If they are not live, fail as before.
Why
Re-tagging a release after a workflow fix is part of the documented release process; the tag-driven build must tolerate the "already published" outcome instead of reporting failure for a successful release.
Problem
With #156 and #158 fixed, the tag-driven deploy now authenticates, uploads and publishes successfully. However a deployment of a version whose artifacts are already live on Maven Central fails validation ("Component with package url ... already exists"), which turns the release job red, skips the Docker publish and the automated PR back to main. This exact case occurred on release/2026.08.30: an earlier run's deployment published the artifacts server-side before its client crashed, so the fully-fixed re-run correctly refused to double-publish and the job went red even though the release is live.
Fix
Wrap the deploy step with an idempotency guard: if
mvn deployfails, check whether the parent and core POMs of the tagged version are already served from repo1.maven.org; if they are, log that the version is already live and exit 0 so the release completes (Docker publish + back-to-main PR). If they are not live, fail as before.Why
Re-tagging a release after a workflow fix is part of the documented release process; the tag-driven build must tolerate the "already published" outcome instead of reporting failure for a successful release.