Perform maven deploy in the main workflow, before tagging the release

[jsenko]

Optionally, perform the tagging and finalization of the release after all intermediate workflows finish successfully.

[EricWittmann]

Let's discuss. I think this change is driven by the recent issues releasing to maven central after our migration away from OSSRH. The pain here is that we did a release and then the deploy-to-maven-central part failed. This leaves us in a state where our source code is tagged but we cannot deploy to central from that tag. Not ideal, for sure.

Previously, our problem was that the deploy-to-maven-central part of our release process would fail with transient sonatype server issues. This would result in us not being able to release our software at all until their servers were up.

Which is the right approach?

[jsenko]

Previously, our problem was that the deploy-to-maven-central part of our release process would fail with transient sonatype server issues. This would result in us not being able to release our software at all until their servers were up.

So we did the release without pushing to Maven (e.g. just images), and then retried mvn deploy until it worked? I get the reasoning, but artifacts in Maven Central are arguably our most important deliverable so it's weird to go with the release anyway.

[EricWittmann]

Well, I think the docker images are a more important deliverable.

In any case, what should the order of operations be?

1. Check out code
2. Change version number (e.g. 3.0.17 sans -SNAPSHOT)
3. Full maven build
4. Deploy to maven central
5. Push pom.xml changes to GitHub
6. Tag and release in GitHub

Is that right? What if the push or tag operations fail for some reason? We could have artifacts in maven central but no tag or release in GH.