Original creation date: 19th September 2019
Note: Originally I posted this on my Wordpress Blog (https://1337codersblog.wordpress.com), but I decided to switch to steemit, so I copied it from there.

Automatical artifact deployment to Maven Central using Gitlab-CI – Part 2

Currently, the artifact is uploaded to Sonatype when a commit is pushed into the master branch of the Gitlab repository. But the release will fail because some rules of the Sonatype repository are not met. We will do this now.

Add information to pom.xml

Add project name, description and project URL to your pom.xml:

    <name>Database Connector</name>
    <description>Library abstracting the logic for accessing databases so that the user of this maven artifact easily can change database implementations without modifying his source code</description>
    <url>https://gitlab.com/marvinh-tradingsystem/databaseconnector</url>

Also you have to add the SCM tag containing the URL to your source code management repository:

    <scm>
        <url>https://gitlab.com/marvinh-tradingsystem/databaseconnector</url>
    </scm>

Add developer information:

<developers>
    <developer>
        <id>MH</id>
        <name>Marvin H.</name>
        <email>[email protected]</email>
        <roles>
            <role>architect</role>
            <role>developer</role>
        </roles>
        <timezone>Europe/Berlin</timezone>
    </developer>
</developers>

Add license information:

<licenses>
    <license>
        <name>MIT License</name>
        <url>https://opensource.org/licenses/MIT</url>
        <distribution>repo</distribution>
    </license>
</licenses>

Altough it is not required for successfully deploying artifacts, you should add the java source version, target version and the source encoding:

<properties>
    <maven.compiler.target>1.8</maven.compiler.target>
    <maven.compiler.source>1.8</maven.compiler.source>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

Add javadoc and sources to artifact

Deploying to Sonatype requires you to also provide jar file containing javadoc and the source code. To do this, you have to add the Javadoc-Plugin and Sources-Plugin:

<build>
    ...
    <plugins>
        ...
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-javadoc-plugin</artifactId>
            <version>3.1.1</version>
            <executions>
                <execution>
                    <id>attach-javadocs</id>
                    <phase>package</phase>
                    <goals>
                        <goal>jar</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-source-plugin</artifactId>
            <version>3.1.0</version>
            <executions>
                <execution>
                    <id>attach-sources</id>
                    <phase>package</phase>
                    <goals>
                        <goal>jar-no-fork</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
        ...
    </plugins>
    ...
</build>

Sign your artifact

Uploading to Maven Central also requires you to sign your artifacts before deploying them. To do this, first create a GnuPG-Key on your local machine:

gpg –gen-key

Enter your Name and your e-mail address. Now you are requested to enter the passphrase for the private key. Leave it blank to create a key without passphrase. You will see the passwort dialog twice.

You have to leave the passphrase empty, because currently it is not possible to provide the passphrase for the key on the shell so the Gitlab-Runner is not able to unlock private keys that are secured with a passphrase.

Export the public key to a file on your local disk as an ASCII-armored version:

gpg –armor –export > PUBLICKEY-FILENAME.asc

Upload your generated key to the SKS keyserver ring. You can do this by visiting pool.sks-keyservers.net. Click on “Submit Key” and paste the content of the created public-key file into the displayed field. It can take some time (minutes to hours) after the upload until the key is available in the keyserver ring for download.

Now export the private key to a file on your local disk as an ASCII-armored version:

gpg –armor –export-secret-keys > SECRETKEY-FILENAME.asc

Note: If you already have multiple secret keys in your GnuPG keyring, you should also provide to the command above the ID of the key to be exported.

Now add a CI-Runner variable GPG_SECRET_KEY of type “File” with the content of the created secret-key file as its value. In part 1 I described how to do this.

Add before_script section for package and deploy stages to your .gitlab-ci.yml:

before_script:
    - gpg --version
    - gpg --import --batch --yes $GPG_SECRET_KEY
    - gpg --list-secret-keys

This will add the private key to the GnuPG keyring of the runner before beginning to package your artifact.

Add this line at the end of the after_script section of the package stage:

- mv target/*.asc .

Add this line at the paths section of the artifact definition in the package stage:

- ./*.asc

Finally your .gitlab-ci.yml should look like this:

image: maven:latest

variables:
  MAVEN_CLI_OPTS: "-s .m2/settings.xml --batch-mode"
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"

cache:
  paths:
    - .m2/repository/
    - target/

stages:
  - build
  - test
  - package
  - deploy

build:
  stage: build
  script:
    - mvn $MAVEN_CLI_OPTS compile

test:
  stage: test
  script:
    - mvn $MAVEN_CLI_OPTS test

package:
  stage: package
  before_script:
    - gpg --version
    - gpg --import --batch --yes $GPG_SECRET_KEY
    - gpg --list-secret-keys
  script:
    - mvn $MAVEN_CLI_OPTS package -Dmaven.test.skip=true
  after_script:
    - mv target/*.jar .
    - mv target/*.asc .
  artifacts:
    paths:
      - ./*.jar
      - ./*.asc

deploy:
  stage: deploy
  before_script:
    - gpg --version
    - gpg --import --batch --yes $GPG_SECRET_KEY
    - gpg --list-secret-keys
  script:
    - mvn $MAVEN_CLI_OPTS clean deploy -Dmaven.test.skip=true
  only:
    - master

Now your commits to the master branch of your Gitlab repository should automatically be deployed and released to Maven Central.

Note: After successfully deploying to Maven Central it will take some time – often some hours – until your deployed artifact is visible to the artifact search and can be downloaded by others.
Automatical artifact deployment to Maven Central using Gitlab-CI – Part 1