В данной статье я хочу подробно рассмотреть процесс публикации с нуля Java артефакта через Github Actions в Sonatype Maven Central Repository используя сборщик Gradle.  Данную статью решил написать ввиду отсутствия нормального туториала в одном месте. Всю информацию приходилось собирать по кускам из различных источников, при том, не совсем свежих. Кому интересно, добро пожаловать под кат. Первым этапом нам нужно создать репозиторий в 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, которые могли бы помочь с публикацией артефакта. Это единственный плагин, который я нашел, однако автор отказался от его дальнейшей поддержки. Поэтому я решил сделать все самостоятельно, благо сделать это не слишком затруднительно.  Первое, что нужно выяснить, это требования Sonatype для публикации. Они следующие: Это основные правила, которые должны быть соблюдены при публикации. Полная информация доступна здесь. Реализуем эти требования в build.gradle файле. Для начала добавим всю необходимую информацию о разработчиках, лицензии, системе контроля версий, а также зададим url, имя и описание проекта. Для этого напишем простой метод: Далее нужно указать, чтобы при сборке сгенерировались -sources.jar и-javadoc.jar файлы. Для этого в секцию java нужно добавить следующее: Перейдем к последнему требованию, настройке GPG/PGP подписи. Для этого подключим плагин signing: И добавим секцию : Наконец, добавим секцию publishing: Здесь sonatypeUsername  и sonatypePassword  переменные, содержащие логин и пароль, созданные при регистрации на sonatype.org. Таким образом, финальный build.gradle будет выглядеть следующим образом: Хочу заметить, что версию мы получаем из переменной среды: System.getenv('RELEASE_VERSION'). Выставлять ее мы будем при сборке и брать из имени тега. Одно из требований Sonatype это подписание всех файлов с помощью GPG/PGP ключа. Для этого идем сюда и качаем утилиту GnuPG под свою операционную систему.  Перейдем к завершающему этапу, настроим сборку и авто публикацию, используя Github Actions.
Github Actions – функционал, позволяющий автоматизировать рабочий процесс, реализовав полный цикл CI/CD. Сборка, тестирование и деплой могут быть вызваны различными событиями: пушинг кода, создание релиза или issues. Данный функционал абсолютно бесплатен для публичных репозиториев. В этом разделе я покажу как настроить сборку и пуше кода и деплой в Sonatype репозиторий при выпуске релиза, а также настройку секретов. Для автоматической сборки и деплоя нам понадобится ряд секретных значений, таких как id ключа, пароль, который мы вводили при генерации ключа, непосредственно сам PGP ключ, а также логин/пароль к Sonatype. Задать их можно в специальном разделе в настройках репозитория:  Задаем следующие переменные: На переменной GPG_KEY_CONTENTS хочу остановится поподробнее. Дело в том, что для публикации нам необходим закрытый PGP ключ. Для того, чтобы разместить его в секретах, я воспользовался инструкцией и дополнительно сделал ряд действий. Для начала нужно создать папку в корне вашего проекта: .github/workflows.  В ней разметить файл, например, gradle-ci-build.yml со следующим содержимым: Данный рабочий процесс будет выполнятся при пуше в ветки 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: Файл практически идентичен предыдущему за исключением события, при котором он будет срабатывать. В данном случае это событие создания тэга с именем, начинающимся на 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 После создания релиза должен запустится рабочий процесс, описанный в предыдущем разделе. Для этого создаем релиз:  при этом имя тега должно начинаться с v. Если после нажатия Publish release, рабочий процесс успешно отработает, мы можем зайти в Sonatype Nexus чтобы в этом убедиться:  Артефакт появился в Staging репозитории. Сразу он появляется в статусе Open, далее его необходимо вручную перевести в статус Close, нажав соответствующую кнопку. После проверки выполнения всех требований, артефакт переходит в статус Close и более не доступен для изменения. В таком виде он попадет в MavenCentral. Если все хорошо, можно нажать кнопку Release, при этом артефакт попадет в репозиторий Sonatype.  Для того, чтобы артефакт попал в MavenCentral, нужно попросить об этом в задаче, которую мы создали в самом начале. Сделать это нужно только один раз, так мы публикуем в первый раз. В последующие разы это делать не требуется, все будет синхронизироваться автоматически. Включили мне синхронизацию быстро, но чтобы артефакт стал доступен в MavenCentral прошло около 5 дней.  На этом все, мы опубликовали наш артефакт в MavenCentral.