Skip to content
Snippets Groups Projects

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

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • added 1 commit

    Compare with previous version

  • @haynes Thanks for your contribution! :100:

    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

  • Author Contributor

    @fcatteau Well, this implements steps 2 and 3 of the implementation plan in gitlab-org/gitlab#6528 (closed) :smiley:

    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.

  • added 3 commits

    Compare with previous version

  • Author Contributor

    rebased the MR and resolved the merge conflicts.
    This is ready for review.

    Edited by Hannes Rosenögger
    • Author Contributor

      @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!

    • Please register or sign in to reply
  • @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?

    • Author Contributor
      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 :smiley:

  • Olivier Gonzalez approved this merge request

    approved this merge request

  • Olivier Gonzalez added 3 commits

    added 3 commits

    • cc6aaf08...3aa7277b - 2 commits from branch gitlab-org/security-products/analyzers:master
    • 99217a4f - Merge branch 'master' into 'maven_central_builds'

    Compare with previous version

  • Olivier Gonzalez approved this merge request

    approved this merge request

  • Olivier Gonzalez enabled an automatic merge when the pipeline for 99217a4f succeeds

    enabled an automatic merge when the pipeline for 99217a4f succeeds

  • mentioned in commit 8c5b91e1

  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Please register or sign in to reply
    Loading