add publishing job to automatically publish releases to maven central
This MR adds all necessary changes to automatically publish new releases to maven central.
Once configured correctly, a new version will be released to maven central for every tag you create.
The version will always equal the tag name to prevent accidental overwrites.
If you want to release a snapshot version to test things make sure the tag name ends with -SNAPSHOT
for example 0.4.0-SNAPSHOT
.
Maven will automatically publish it to the snapshot repository instead of the releases repository.
To set this up you will need to configure 4 secret variables:
Keyy | Value |
---|---|
OSSRH_USER | the username used to login to oss.sonatype.org (can be the user value of an access token as well) |
OSSRH_PWD | the password used to login to oss.sonatype.org (can be the password value of an access token as well) |
GPG_PASSPHRASE | The passphrase for the private gpg key |
GPG_PRIVATE_KEY | The private gpg key |
The gpg key can be a newly created key. Only requirement is, that the public key is published to a keyserver.
See this link for how to do that.
https://central.sonatype.org/pages/working-with-pgp-signatures.html#distributing-your-public-key
Keep in mind that it can take a few hours to propagate the key to the different keyservers after you publish it.
closes #5
/cc @gonzoyumo @fcatteau
Merge request reports
Activity
- Resolved by Olivier Gonzalez
- Resolved by Olivier Gonzalez
added Community contribution label
@haynes Thanks for your contribution!
This issue has not been assigned. Is it ready for review? Assigning to you, to make explicit that no one is reviewing this at the moment. Please assign to @gonzoyumo or myself when it's ready. Thanks!
/cc @ifrenkel
assigned to @haynes
@fcatteau Well, this implements steps 2 and 3 of the implementation plan in gitlab-org/gitlab#6528 (closed)
I'm assigning this to @gonzoyumo so he can simply merge this to finish the issue when he has set up his credentials.
I'll rebase this MR to resolve the merge conflicts later today.
assigned to @gonzoyumo
added 3 commits
-
a1684f52...0189abe5 - 2 commits from branch
gitlab-org/security-products/analyzers:master
- cc6aaf08 - add publishing job
-
a1684f52...0189abe5 - 2 commits from branch
rebased the MR and resolved the merge conflicts.
This is ready for review.Edited by Hannes Rosenögger@gonzoyumo short reminder as this MR has been open for 2 month without any feedback now.
@haynes I apologize for the delay and thank you for the kind reminder. The corresponding issue has been postponed multiple times due to low capacity and I've lost sight of it. We also have several other ~backstage changes that bring more value than moving this repo which makes it harder to prioritize.
Though, as this is a Community contribution we definitely should be paying more attention to it. It is currently in %12.9 but there are good chances we'll pick it up in %12.8.
Thanks for your help in maintaining this project and your patience!
@haynes I'm finally able to have a look at this and I'm realizing there might be security concern with doing it.
By putting the PGP passphrase and private key in variables, they could leak in a job log very easily. This could come from tuning the
.gitlab-ci.yml
file or getting access to the project's settings. And anyone getting these items can sign objects on my behalf (name and email), even without me being aware of it.We can make them protected to limit the exposure but it looks like multiline variables can't be masked: https://gitlab.com/help/ci/variables/README#masked-variables, which increases the risk for the private key.
This makes me reluctant to proceed with this approach. Am I being too paranoid on this?
- Resolved by Olivier Gonzalez
@gonzoyumo maybe a little bit too paranoid ;)
The only time the private key variable is being used directly in the
.gitlab-ci.yml
is this line, which produces the following output:$ (echo $GPG_PASSPHRASE | gpg --batch --no-tty --yes --import <(echo "$GPG_PRIVATE_KEY")) >/dev/null gpg: directory '/root/.gnupg' created gpg: keybox '/root/.gnupg/pubring.kbx' created gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key 2A7216A888A8ED69: public key "Hannes Rosenögger <123haynes@gmail.com>" imported gpg: key 2A7216A888A8ED69: secret key imported gpg: Total number processed: 1 gpg: imported: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1
I don't see how the variables could leak in job logs easily.
Maybe add a comment above this line saying "never change it!!!!!!!!!!!!!"
Once the job is implemented, there shouldn't be a reason to edit it anyway.Alternatively, you could create a private docker image with the private key already imported and set as environment variables.
And anyone getting these items can sign objects on my behalf (name and email), even without me being aware of it.
While that is a small risk of course if both the private key and the passphrase are leaked, I don't think you need to worry about it to much. The PGP key is not tied to your name or ossrh account. You can specify a random mail and username in the key. i.e. "Automated gemnasium maven plugin Releaseuser 123@gitlab.com" Also note that you can always revoke your key as long as you have access to your private key.
If you have some time today/tomorrow I'm also happy to join a zoom call to directly answer any questions/worries you might have. Not sure if I was able to express what I wanted to convey completely in text.
Just let me know
added 3 commits
-
cc6aaf08...3aa7277b - 2 commits from branch
gitlab-org/security-products/analyzers:master
- 99217a4f - Merge branch 'master' into 'maven_central_builds'
-
cc6aaf08...3aa7277b - 2 commits from branch
enabled an automatic merge when the pipeline for 99217a4f succeeds
mentioned in commit 8c5b91e1