В данной статье я хочу подробно рассмотреть процесс публикации с нуля Java артефакта через Github Actions в Sonatype Maven Central Repository используя сборщик Gradle.
Данную статью решил написать ввиду отсутствия нормального туториала в одном месте. Всю информацию приходилось собирать по кускам из различных источников, при том, не совсем свежих. Кому интересно, добро пожаловать под кат.
Создание репозитория в Sonatype
Первым этапом нам нужно создать репозиторий в Sonatype Maven Central. Для этого идем сюда, регистрируемся и создаем новую задачу, с просьбой создать нам репозиторий. Вбиваем свой GroupId проекта, Project URL ссылку на проект и SCM url ссылку на систему контроля версий, в которой проект лежит. GroupId здесь должен быть вида com.example, com.example.domain, com.example.testsupport, а также может быть в виде ссылки на ваш гитхаб: github.com/yourusername -> io.github.yourusername. В любом случае, вам нужно будет подтвердить владение данным доменом или профилем. Если вы указали профиль гитхаба, попросят создать публичный репозиторий с нужным именем.
Через некоторое время после подтверждения ваш GroupId будет создан и мы можем перейти к следующему шагу, конфигурации Gradle.
Конфигурируем Gradle
На момент написания статьи я не нашел плагинов для Gradle, которые могли бы помочь с публикацией артефакта. Это единственный плагин, который я нашел, однако автор отказался от его дальнейшей поддержки. Поэтому я решил сделать все самостоятельно, благо сделать это не слишком затруднительно.
Первое, что нужно выяснить, это требования Sonatype для публикации. Они следующие:
- Наличие исходных кодов и JavaDoc, т.е. должны присутствовать
-sources.jarи-javadoc.jarфайлы. Как сказано в документации, если нет возможно предоставить исходные коды или документацию, можно сделать пустышку-sources.jarили-javadoc.jarc простым README внутри, чтобы пройти проверку. - Все файлы должны быть подписаны с помощью
GPG/PGP, и.ascфайл, содержащий подпись, должен быть включен для каждого файла. - Наличие
pomфайла - Корректные значения
groupId,artifactIdиversion. Версия может быть произвольной строкой и не может заканчиваться-SNAPSHOT - Необходимо присутствие
name,descriptionиurl - Присутствие информации о лицензии, разработчиках и системе контроля версий
Это основные правила, которые должны быть соблюдены при публикации. Полная информация доступна здесь.
Реализуем эти требования в build.gradle файле. Для начала добавим всю необходимую информацию о разработчиках, лицензии, системе контроля версий, а также зададим url, имя и описание проекта. Для этого напишем простой метод:
def customizePom(pom) {
pom.withXml {
def root = asNode()
root.dependencies.removeAll { dep ->
dep.scope == "test"
}
root.children().last() + {
resolveStrategy = DELEGATE_FIRST
description 'Some description of artifact'
name 'Artifct name'
url 'https://github.com/login/projectname'
organization {
name 'com.github.login'
url 'https://github.com/login'
}
issueManagement {
system 'GitHub'
url 'https://github.com/login/projectname/issues'
}
licenses {
license {
name 'The Apache License, Version 2.0'
url 'http://www.apache.org/licenses/LICENSE-2.0.txt'
}
}
scm {
url 'https://github.com/login/projectname'
connection 'scm:https://github.com/login/projectname.git'
developerConnection 'scm:git://github.com/login/projectname.git'
}
developers {
developer {
id 'dev'
name 'DevName'
email 'email@dev.ru'
}
}
}
}
}Далее нужно указать, чтобы при сборке сгенерировались -sources.jar и-javadoc.jar файлы. Для этого в секцию java нужно добавить следующее:
java {
withJavadocJar()
withSourcesJar()
}Перейдем к последнему требованию, настройке GPG/PGP подписи. Для этого подключим плагин signing:
plugins {
id 'signing'
}И добавим секцию :
signing {
sign publishing.publications
}Наконец, добавим секцию publishing:
publishing {
publications {
mavenJava(MavenPublication) {
customizePom(pom)
groupId group
artifactId archivesBaseName
version version
from components.java
}
}
repositories {
maven {
url "https://oss.sonatype.org/service/local/staging/deploy/maven2"
credentials {
username sonatypeUsername
password sonatypePassword
}
}
}
}Здесь sonatypeUsername и sonatypePassword переменные, содержащие логин и пароль, созданные при регистрации на sonatype.org.
Таким образом, финальный build.gradle будет выглядеть следующим образом:
plugins {
id 'java'
id 'maven-publish'
id 'signing'
}
java {
sourceCompatibility = JavaVersion.VERSION_1_8
targetCompatibility = JavaVersion.VERSION_1_8
withJavadocJar()
withSourcesJar()
}
group 'io.github.githublogin'
archivesBaseName = 'projectname'
version = System.getenv('RELEASE_VERSION') ?: "0.0.1"
repositories {
mavenCentral()
}
dependencies {
testImplementation 'org.junit.jupiter:junit-jupiter-api:5.5.2'
testRuntimeOnly 'org.junit.jupiter:junit-jupiter-engine:5.5.2'
}
test {
useJUnitPlatform()
}
jar {
from sourceSets.main.output
from sourceSets.main.allJava
}
signing {
sign publishing.publications
}
publishing {
publications {
mavenJava(MavenPublication) {
customizePom(pom)
groupId group
artifactId archivesBaseName
version version
from components.java
}
}
repositories {
maven {
url "https://oss.sonatype.org/service/local/staging/deploy/maven2"
credentials {
username sonatypeUsername
password sonatypePassword
}
}
}
}
def customizePom(pom) {
pom.withXml {
def root = asNode()
root.dependencies.removeAll { dep ->
dep.scope == "test"
}
root.children().last() + {
resolveStrategy = DELEGATE_FIRST
description 'Some description of artifact'
name 'Artifct name'
url 'https://github.com/login/projectname'
organization {
name 'com.github.login'
url 'https://github.com/githublogin'
}
issueManagement {
system 'GitHub'
url 'https://github.com/githublogin/projectname/issues'
}
licenses {
license {
name 'The Apache License, Version 2.0'
url 'http://www.apache.org/licenses/LICENSE-2.0.txt'
}
}
scm {
url 'https://github.com/githublogin/projectname'
connection 'scm:https://github.com/githublogin/projectname.git'
developerConnection 'scm:git://github.com/githublogin/projectname.git'
}
developers {
developer {
id 'dev'
name 'DevName'
email 'email@dev.ru'
}
}
}
}
}Хочу заметить, что версию мы получаем из переменной среды: System.getenv('RELEASE_VERSION'). Выставлять ее мы будем при сборке и брать из имени тега.
Генерация PGP ключа
Одно из требований Sonatype это подписание всех файлов с помощью GPG/PGP ключа. Для этого идем сюда и качаем утилиту GnuPG под свою операционную систему.
- Генерируем ключевую пару:
gpg --gen-key, вводим имя пользователя, e-mail, а также задаем пароль. - Выясняем
idнашего ключа командой:gpg --list-secret-keys --keyid-format short. Id будет указан после слеша, например: rsa2048/9B695056 - Публикуем публичный ключ на сервер https://keys.openpgp.org командой:
gpg --keyserver [https://keys.openpgp.org](https://keys.openpgp.org/) --send-keys 9B695056 - Экспортируем секретный ключ в произвольное место, он нам понадобится в дальнейшем:
gpg --export-secret-key 9B695056 > D:\\gpg\\9B695056.gpg
Настраиваем Github Actions
Перейдем к завершающему этапу, настроим сборку и авто публикацию, используя Github Actions.
Github Actions – функционал, позволяющий автоматизировать рабочий процесс, реализовав полный цикл CI/CD. Сборка, тестирование и деплой могут быть вызваны различными событиями: пушинг кода, создание релиза или issues. Данный функционал абсолютно бесплатен для публичных репозиториев.
В этом разделе я покажу как настроить сборку и пуше кода и деплой в Sonatype репозиторий при выпуске релиза, а также настройку секретов.
Задаем секреты
Для автоматической сборки и деплоя нам понадобится ряд секретных значений, таких как id ключа, пароль, который мы вводили при генерации ключа, непосредственно сам PGP ключ, а также логин/пароль к Sonatype. Задать их можно в специальном разделе в настройках репозитория:
Задаем следующие переменные:
- SONATYPE_USERNAME/SONATYPE_PASSWORD — логин/пароль, который мы вводили при регистрации в Sonatype
- SIGNING_KEYID/SIGNING_PASSWORD — id PGP ключа и пароль, установленный при генерации.
На переменной GPG_KEY_CONTENTS хочу остановится поподробнее. Дело в том, что для публикации нам необходим закрытый PGP ключ. Для того, чтобы разместить его в секретах, я воспользовался инструкцией и дополнительно сделал ряд действий.
- Зашифруем наш ключ с помощью gpg:
gpg --symmetric --cipher-algo AES256 9B695056.gpg, введя пароль. Его следует поместить в переменную: SECRET_PASSPHRASE - Переведем полученный зашифрованный ключ в текстовый форма с помощью base64:
base64 9B695056.gpg.gpg > 9B695056.txt. Содержимое разместим в переменной: GPG_KEY_CONTENTS.
Настройка сборки при пуше кода и создании PR
Для начала нужно создать папку в корне вашего проекта: .github/workflows.
В ней разметить файл, например, gradle-ci-build.yml со следующим содержимым:
name: build
on:
push:
branches:
- master
- dev
- testing
pull_request:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Set up JDK 8
uses: actions/setup-java@v1
with:
java-version: 8
- name: Build with Gradle
uses: eskatos/gradle-command-action@v1
with:
gradle-version: current
arguments: build -PsonatypeUsername=${{secrets.SONATYPE_USERNAME}} -PsonatypePassword=${{secrets.SONATYPE_PASSWORD}}Данный рабочий процесс будет выполнятся при пуше в ветки master, dev и testing, также при создании пулл реквестов.
В секции jobs указаны шаги, которые должны выполнится по указанным событиям. В данном случае собирать мы будем на последней версии ubuntu, использовать Java 8, а также использовать плагин для Gradle eskatos/gradle-command-action@v1, который используя последнюю версию сборщика запустит команды, указанные в arguments. Переменные secrets.SONATYPE_USERNAME и secrets.SONATYPE_PASSWORD это секреты, которые мы задали ранее.
Результаты сборки будут отражены во вкладке Actions:
Автодеплой при выпуске нового релиза
Для автодеплоя создадим отдельный файл рабочего процесса gradle-ci-publish.yml:
name: publish
on:
push:
tags:
- 'v*'
jobs:
publish:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
- name: Set up JDK 8
uses: actions/setup-java@v1
with:
java-version: 8
- name: Prepare to publish
run: |
echo '${{secrets.GPG_KEY_CONTENTS}}' | base64 -d > publish_key.gpg
gpg --quiet --batch --yes --decrypt --passphrase="${{secrets.SECRET_PASSPHRASE}}" \
--output secret.gpg publish_key.gpg
echo "::set-env name=RELEASE_VERSION::${GITHUB_REF:11}"
- name: Publish with Gradle
uses: eskatos/gradle-command-action@v1
with:
gradle-version: current
arguments: test publish -Psigning.secretKeyRingFile=secret.gpg -Psigning.keyId=${{secrets.SIGNING_KEYID}} -Psigning.password=${{secrets.SIGNING_PASSWORD}} -PsonatypeUsername=${{secrets.SONATYPE_USERNAME}} -PsonatypePassword=${{secrets.SONATYPE_PASSWORD}}Файл практически идентичен предыдущему за исключением события, при котором он будет срабатывать. В данном случае это событие создания тэга с именем, начинающимся на v.
Перед деплоем нам нужно вытянуть PGP ключ из секретов и разместить его в корне проекта, а также расшифровать его. Далее нам нужно выставить специальную переменную среды RELEASE_VERSION к которой мы обращаемся в gradle.build файле. Все это сделано в разделе Prepare to publish. Мы получаем наш ключ из переменной GPG_KEY_CONTENTS, переводим его в gpg файл, затем расшифровываем его, помещая в файл secret.gpg.
Далее мы обращаемся к специальной переменной GITHUB_REF, из которой можем достать версию, которую мы задали при создании тега. Данная переменная в этом случае имеет значение refs/tags/v0.0.2 из которой мы отрезаем первые 11 символов, чтобы достать конкретно версию. Далее стандартно используем команды Gradle для публикации: test publish
Проверка результатов деплоя в Sonatype репозиторий
После создания релиза должен запустится рабочий процесс, описанный в предыдущем разделе. Для этого создаем релиз:
при этом имя тега должно начинаться с v. Если после нажатия Publish release, рабочий процесс успешно отработает, мы можем зайти в Sonatype Nexus чтобы в этом убедиться:
Артефакт появился в Staging репозитории. Сразу он появляется в статусе Open, далее его необходимо вручную перевести в статус Close, нажав соответствующую кнопку. После проверки выполнения всех требований, артефакт переходит в статус Close и более не доступен для изменения. В таком виде он попадет в MavenCentral. Если все хорошо, можно нажать кнопку Release, при этом артефакт попадет в репозиторий Sonatype.
Для того, чтобы артефакт попал в MavenCentral, нужно попросить об этом в задаче, которую мы создали в самом начале. Сделать это нужно только один раз, так мы публикуем в первый раз. В последующие разы это делать не требуется, все будет синхронизироваться автоматически. Включили мне синхронизацию быстро, но чтобы артефакт стал доступен в MavenCentral прошло около 5 дней.
На этом все, мы опубликовали наш артефакт в MavenCentral.
Полезные ссылки
- Похожая статья, только публикация через maven
- Staging репозиторий Sonatype
- Jira Sonatype, в которой необходимо создать задачу
- Пример репозитория, где это все настроено
