Question about a release versus snapshot use case

[xgp]

Thank you for this action. Before I invest the time in the setup, I'm trying to understand if I can make this work with my use case. The setup documentation is pretty clear, but the documentation seems light on what the actual side effects are.

Does this do a normal mvn release:prepare and mvn release:perform with the specified major/minor/patch version bump?

Does it do anything with sonatype to automate the closing of the staging repository that is created?

I'd like to:

1. make a SNAPSHOT release (no version bump) to maven central with each commit to master
2. make a release to maven central when there is a tag created
3. not have to manually log into sonatype to close the staging repository

Is it possible to configure the action for this use?

[qcastel]

Hello @xgp ,

Behind the scene, this github action is a simple wrapper of the maven release https://maven.apache.org/maven-release/maven-release-plugin/ You can therefore expect to be able what ever is supported by maven release.

I did a sample repo that may help you visualise what you could do with maven release and this github action:

https://github.com/gh-a-sample/github-actions-maven-release-sample

To your particular questions:

Does this do a normal mvn release:prepare and mvn release:perform with the specified major/minor/patch version bump?

yes, that's what it does, if you configure it that way. The git history looks like this in the sample repo:

make a SNAPSHOT release (no version bump) to maven central with each commit to master

I guess that's usually not what people are using maven release for, as they tends to want to release their version and hence bump the version at the same time. Although it may be possible to do this, by playing with : https://github.com/qcastel/github-actions-maven-release#customize-version The doc from maven release about the version variable is here: https://www.mojohaus.org/build-helper-maven-plugin/parse-version-mojo.html

Maybe do something like

            maven-development-version-number: ${parsedVersion.majorVersion}.\${parsedVersion.minorVersion}.\${parsedVersion. incrementalVersion}-
SNAPSHOT

(again, it's a bit usually to not increment a version during a release, perhaps an alternative for you would be to bump the buildNumber ? )

I also found this article that explains how to push snapshots https://www.baeldung.com/maven-snapshot-release-repository I guess it's possible ootb, I just never tried myself.

If you are stuck and the wrapper of this maven release CI is blocking you, raise an issue and I can fix that.

make a release to maven central when there is a tag created

Yes, you can achieve that. The idea is to setup your pom.xml accordingly, something like this article suggest https://medium.com/@kkdthunlshd/publish-github-project-in-maven-central-repository-bdf0e5aa2b82

not have to manually log into sonatype to close the staging repository

That would'nt be on the realm of maven release, although as this github action does a classic mvn release:perform, you can follow the doc of sonatype for that: https://help.sonatype.com/repomanager2/staging-releases/configuring-your-project-for-deployment

In particular you can trigger the nexus-staging-maven-plugin at the right phase, which would do what you want.

Hope this help you in your CI journey.

[xgp]

@qcastel Thanks for the additional context. I am getting close to a working version. One of the things that is not addressed is the signing of maven artifacts using GPG. I see in the example that GPG is used for git commit signing, but there is no documentation/examples of how to use GPG for maven artifact signing, as required by Maven Central. Are there examples of that somewhere? Thanks!

[qcastel]

I think what you want is documented here:

https://maven.apache.org/plugins/maven-gpg-plugin/usage.html

You will then wonder how to setup the GPG key in the settings.xml. That, you can setup the GPG like for the commit. This github action will behind the scene generate a settings.xml using the template: https://github.com/qcastel/docker-maven-release/blob/master/settings-template.xml#L17

The GPG key will be used for signing commit but if you set your pom.xml to use the maven gpg plugin, it will also sign the artefacts with it.

[xgp]

Hi @qcastel, thanks again for all your help with this. Still stuck on GPG.

For some additional context, here is the repo I'm working with: https://github.com/xgp/oss-parent It is a repo that currently builds, increments versions, tags in git, deploys and releases to Maven Central (with GPG artifact signing and automatic staging repository close) using mvn release:prepare and mvn release:perform

I added your release action and configured it like this: https://github.com/xgp/oss-parent/blob/master/.github/workflows/release.yml

The build fails when trying to import the GPG key:

Import the GPG key
gpg: directory '/github/home/.gnupg' created
gpg: keybox '/github/home/.gnupg/pubring.kbx' created
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

https://github.com/xgp/oss-parent/actions/runs/3464889222/jobs/5786971726

I've got these secrets in the Actions secrets of the repository:

And the GPG public key set up in the bot's account keys:

Am I missing anything obvious?

[qcastel]

Thanks for the github sponsoring! Really appreciate, will use this sponsoring wisely by buying a beer on your honor next time I go to the pub! (so tomorrow then ;p )

To your issue, here is what I do to import the gpg key:

echo "Import the GPG key"
echo  "$GPG_KEY" | base64 -d > private.key
gpg --batch --import ./private.key

As you can see, nothing over complicated. The obvious things to check before going further, would be if:

• you haven't put the public key by mistake behind the GPG_KEY
• you did put the private key base 64 encoded? The doc of the github action is directing you that way but perhaps you did follow another doc for the gpg key. https://github.com/qcastel/github-actions-maven-release#get-the-gpg-public-and-private-key

If not then I may have some other ideas to unblock you, as docker exec the image and generating the gpg key directly from there. That would remove any OS related issue:

docker run -it qcastel/maven-release:0.0.38 bash

And then following the GPG doc section but this time from the container: https://github.com/qcastel/github-actions-maven-release#generate-the-key

btw thats one reason I did use a docker image, it's to be able to reproduce things more easily by spinning up the container. You may find this trick quite handy.

[xgp]

I feel like I owe you more than a 🍺 at this point.

Thanks for the advice. It was the lack of base64 encoding of my GPG key. However, now I'm stuck on another GPG problem. When maven tries to commit, there is a failure to sign: [ERROR] error: gpg failed to sign the data https://github.com/xgp/oss-parent/actions/runs/3468465916/jobs/5794309942#step:6:1011

The key seems to have installed properly, and the logs for the rest of the maven build look right, but it just outputs an uninformative message. I've done some googling, and I can't find anything similar.

[qcastel]

I am wondering if it's just nto a problem of kid.

Basically at this point, it's git that is actually returning the error. Git doesn't managed to sign the commit. Can you verify that the value of your kid is correct?

secrets.GPG_KEY_ID=59242F8D867FE304

From your log, thats your KID

btw I suggested to put it in the secrets but in reality, the kid is not secret at all. It coudl be directly added to the yaml. I think I originally did it this way as I was in the secret section of github and it was convenient to add it here.

[xgp]

Interesting. It's part of the KID:

[garth:oss-parent (master)]$ gpg --list-keys
/Users/garth/.gnupg/pubring.kbx
-------------------------------
pub   rsa3072 2022-11-14 [SC]
      EE987E9D73D27204E4F2C15359242F8D867FE304
uid           [ultimate] Phase Two Support <support@phasetwo.io>
sub   rsa3072 2022-11-14 [E] [expires: 2024-11-13]

The KID that is listed is EE987E9D73D27204E4F2C15359242F8D867FE304, which is the value I have stored as secrets.GPG_KEY_ID. The last bit is the part that gets printed. Am I doing something obviously wrong here?

[xgp]

Changing the secrets.GPG_KEY_ID value to 59242F8D867FE304 doesn't help.

[qcastel]

At this point, I believe it's just a matter of making this key work with git. GPG tends to be quite unhelpful and I did struggle in the past with similar situation.

What this mean is you could troubleshoot it using documentation on the subject.

For troubleshooting this, I would try to decompose the problem in steps:

1) Setup a GPG Key on your main github account, following the github GPG documentation perhaps, instead of my doc. 2) verifying that you can do a dummy commit to your repo and it does appeared as signed in github 3) Generate a new key exactly the same way (perhaps in a container? Just so you don't pollute your main OS too much) and assign it to the bot user 4) Verify that you can commit as the bot and it's indeed signed commit 5) Configure the github action with this key and check that the github action is able to sign commit

A bit cumbersome to have to do that but I guess it would take you less time, as you would be able to identify the issue more clearly.

[qcastel]

I would try that: https://docs.github.com/en/github-ae@latest/authentication/managing-commit-signature-verification/generating-a-new-gpg-key

Doesn't look very different to what I suggest in this github action but who knows, perhaps it's slighly different.

Again, don't know if you are familiar with docker but perhaps do the testing on a docker container with your git repo code attach to it. This way you can do commits directly on the container and test it in a closer environemnt to the CI

[qcastel]

You can btw just try the key 59242F8D867FE304 on your normal github account and see. You will most likely reproduce the same issue

[xgp]

Hooray! I must have done something wrong in the key creation/exporting, as it works now. Thanks for your help. I'm on to some other maven central problems, but those are not related to this action.

[qcastel]

Glad you found the solution at the end. All the best in your CI journey