search

ocpsoft / rewrite

OCPsoft URL-Rewriting Framework
http://ocpsoft.org/rewrite/
Apache License 2.0
189 stars 86 forks source link

Automate pushing of snapshots and tagged releases to Maven Central with GitHub Action/s #351

Open poikilotherm opened 2 years ago

poikilotherm commented 2 years ago

This is a follow up to a comment (https://github.com/ocpsoft/rewrite/pull/350#issuecomment-1293806202)

Currently, no snapshots are released to Sonatype OSS. (There is no https://s01.oss.sonatype.org/content/repositories/snapshots/org/ocpsoft) Snapshots are never deleted, see here for an example.

We should add proper plugin configuration to our main POM plus embed them in a CD pipeline.

One might argue we should also add a release profile and CD pipeline to automate pushing tagged releases.

Doing this for:

lincolnthree commented 2 years ago

Interesting. Thanks. At one point I had CI set up to deploy snapshots to OSSRH with Jenkins, but... that was a long time ago and that server is... gone. I agree. It would be nice to have an automated release profile and CD pipeline.

As I'm not really up to speed with the GitHub CI stuff (obviously), I assume it would mean that Git tags pushed to GitHub (or cut on GitHhub) would create releases via this pipeline?

By release profile, you mean Maven profile?

What would be entailed in doing this?

poikilotherm commented 2 years ago

Apparently, the merged pipeline worked right away! See here for an example: https://oss.sonatype.org/content/repositories/snapshots/org/ocpsoft/rewrite/rewrite-servlet/6.0.0-SNAPSHOT

So, I'm going to create more PRs for the other branches containing the same content.

I'll also add a new PR with a release pipeline, so you can take a closer look and think about if this would be helpful.

WRT your question: yes, so far I did this in my other projects with a Maven profile so it can be included for mvn deploy when doing a release from a tag.

You can see the profile here as an example: https://github.com/gdcc/xoai/blob/eb02cf39544fd865d66670620b6788a194f38c0a/pom.xml#L541-589

Yes, the release pipeline would be triggered on any git tag push or Github release (which adds a tag).

What I woukd need from you in order to make this happen if you want this: repository secrets with the GPG key to sign this stuff. I can show you a screenshot from my other little libs how this should look like.

Here is an example of the Github action I'm using in these places: https://github.com/gdcc/xoai/blob/branch-5.0/.github/workflows/maven-release.yml

If you don't feel comfortable with storing that GPG key on Github, IIRC there was some project doing a combined approach with local keys. Would need to look that one up again.

lincolnthree commented 2 years ago

I'll also add a new PR with a release pipeline, so you can take a closer look and think about if this would be helpful.

Great! Let's do it. Right now I do all releasing and GPG key management locally. It would be nice to immortalize that into github and make future maintenance (and collaboration with other maintainers) easier.

What I woukd need from you in order to make this happen if you want this: repository secrets with the GPG key to sign this stuff. I can show you a screenshot from my other little libs how this should look like.

I can set these up like the SONATYPE_USERNAME/PASSWORD, etc. Just let me know what you need. I assume that's what you mean.

If you don't feel comfortable with storing that GPG key on Github, IIRC there was some project doing a combined approach with local keys. Would need to look that one up again.

I will need to think about this. GPG is supposed to identify a person, not a CI build. Perhaps I could create new GPG keys specifically for GitHub, though I'm not 100% sure how that all works anymore since it's been like 14 years since I set it up. Lol.

Any idea/references on best practices WRT this?

poikilotherm commented 2 years ago

I don't have a reference for a good practice on this, sorry. Personally, I created a new GPG key just for signing this in CI, not attached to my person:

grafik

I added this key (obviously the private key, not the public one) to the Github repo secrets (or in this case to the org):

grafik

I have been following parts of this tutorial (and others), but the important part is about extracting the GPG key to store in the secret.

poikilotherm commented 2 years ago

@lincolnthree it would be pretty cool if you could create these two GPG secrets and let me know how you named 'em, so I can pick them up.

lincolnthree commented 2 years ago

@lincolnthree it would be pretty cool if you could create these two GPG secrets and let me know how you named 'em, so I can pick them up.

Fantastic. I will work on this! Thank you!