Added workflows to publish snapshots and releases to Maven Central.

[dblock]

Signed-off-by: Daniel (dB.) Doubrovkine dblock@amazon.com

Highly inspired from https://github.com/aws/random-cut-forest-by-aws/pull/334 and https://docs.github.com/en/actions/publishing-packages/publishing-java-packages-with-maven.

Will need MAVEN_GPG_PRIVATE_KEY, MAVEN_GPG_PASSPHRASE, OSSRH_USERNAME and OSSRH_TOKEN in repo secrets. There's a pretty good explanation in https://dzone.com/articles/how-to-publish-artifacts-to-maven-central of how to get all those things if you need help.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[acm19]

@dblock could you have a look now? I've updated the release process so if you have all the needed tools installed in your machine by running make release 2 pull request will be raised one for the release and one for the next working version as draft. Maintainer have to merge them in order, everything else should be automatic. The idea being if this works well an automation can be added to avoid the PRs and do the same directly on master.

If it looks good to you I'll write the RELEASING.md, I'll just hold it in case some changes are needed. The commands were mostly written by heart or tested in Linux, if you are using a different platform they might not work exactly the same.

[dblock]

Btw, if you want to push some limits and really make something spectacular, you could implement all of the stuff in Makefile in GitHub actions. The release would be a 1-click workflow executed on demand that opens a PR to make a release (won't need tools like gh, makefiles, etc.). And when a release happened (a tag was created) a workflow would make a PR to increment for the next development iteration. I don't know of a maven repo that has all these, but here's an example of something triggered on tags that opens PRs: https://github.com/opensearch-project/OpenSearch/blob/main/.github/workflows/version.yml.

[dblock]

One more thing. Any reason not to create a SNAPSHOT build with every build automatically? Do we need a Makefile target?

[acm19]

@dblock on your comments for the PR:

One more thing. Any reason not to create a SNAPSHOT build with every build automatically? Do we need a Makefile target?

This is the case at the moment. On push to master a there is a deploy to Maven, I modified the workflow so it will happen regardless of it being SNAPSHOT or not. If it's not SNAPTHOT then a tag is generated, but it will deploy to Maven every push to master.

Btw, if you want to push some limits and really make something spectacular, you could implement all of the stuff in Makefile in GitHub actions. The release would be a 1-click workflow executed on demand that opens a PR to make a release (won't need tools like gh, makefiles, etc.). And when a release happened (a tag was created) a workflow would make a PR to increment for the next development iteration. I don't know of a maven repo that has all these, but here's an example of something triggered on tags that opens PRs: https://github.com/opensearch-project/OpenSearch/blob/main/.github/workflows/version.yml.

That's the idea, but I thought I'd do it in 2 steps. First make it work manually to enable releasing and create a new ticket to automate it. Although, I don't plan to create PR once it's automatic, but rather push a button: that creates first commit with the snapshot removed and the changelog updated, push to master, then create second commit with the next snapshot version and the changelog updated. That will trigger the workflow that already exists and it's fully automated. But that will take me a bit longer as I haven't played much with GitHub actions and I didn't want to keep holding the release on it being perfect, but it will def be soon. Thank you for the example, it's helpful. WDYT?

[dblock]

@dblock on your comments for the PR:

One more thing. Any reason not to create a SNAPSHOT build with every build automatically? Do we need a Makefile target?

This is the case at the moment. On push to master a there is a deploy to Maven, I modified the workflow so it will happen regardless of it being SNAPSHOT or not. If it's not SNAPTHOT then a tag is generated, but it will deploy to Maven every push to master.

Btw, if you want to push some limits and really make something spectacular, you could implement all of the stuff in Makefile in GitHub actions. The release would be a 1-click workflow executed on demand that opens a PR to make a release (won't need tools like gh, makefiles, etc.). And when a release happened (a tag was created) a workflow would make a PR to increment for the next development iteration. I don't know of a maven repo that has all these, but here's an example of something triggered on tags that opens PRs: https://github.com/opensearch-project/OpenSearch/blob/main/.github/workflows/version.yml.

That's the idea, but I thought I'd do it in 2 steps. First make it work manually to enable releasing and create a new ticket to automate it. Although, I don't plan to create PR once it's automatic, but rather push a button: that creates first commit with the snapshot removed and the changelog updated, push to master, then create second commit with the next snapshot version and the changelog updated. That will trigger the workflow that already exists and it's fully automated. But that will take me a bit longer as I haven't played much with GitHub actions and I didn't want to keep holding the release on it being perfect, but it will def be soon. Thank you for the example, it's helpful. WDYT?

I agree that we don't need PRs where we can just commit/release, and this is simpler!

If you want to merge this change as is and make a release, that's more than OK with me. Up to you.

[acm19]

Good, I'll tackle it separately then: https://github.com/acm19/aws-request-signing-apache-interceptor/issues/53. I want to try the release and make sure that works. Also there are some outstanding problems we haven't solved yet.