Этот пост является продолжением серии советов и подсказок по JitPack. В первом посте этой серии речь шла об уникальном репозитории Maven под названием JitPack, который собирает артефакты зависимостей по требованию из git-репозитория, и объяснялось, как настроить ваш репозиторий для успешной сборки с последними версиями JDK, по сути, рассказывалось о том, что я должен был сделать, чтобы сборки JitPack работали для одной из моих библиотек, требующей JDK 17. Отказ от ответственности: я не связан с JitPack, и это не официальная документация.

В этой части мы рассмотрим, как использовать предпочитаемый вами Maven groupId с JitPack, а не установленный по умолчанию JitPack com.github.USER (или аналогичный для других git-хостов). Что еще более важно, мы увидим, как это эффективно делать с опережающими сборками. JitPack предназначен для сборок по требованию, но включает веб-крючок, который вы можете настроить в своем репозитории GitHub или Bitbucket для включения опережающих сборок. Однако нет встроенного способа сделать то же самое для настраиваемого groupId, например, обычного обратного доменного имени. Трюк, описанный в этой заметке, также может быть полезен тем, кто использует JitPack с git-хостом, который в настоящее время не поддерживается веб-крюками JitPack.

Кроме того, описанный в этом посте прием использует рабочие процессы GitHub Actions, но вы должны быть в состоянии адаптировать эту технику к CI/CD-фреймворкам других git-хостов или даже к сценарию оболочки.

Оглавление: Остальная часть этого поста организована следующим образом:

• Как использовать JitPack с настроенным groupId
• Как создавать опережающие сборки с настроенным groupId
• Рабочие процессы GitHub Actions для опережающих сборок JitPack
• Где вы можете найти меня

Как использовать JitPack с настроенным groupId

Maven Central и другие репозитории Maven обычно используют обратный домен или поддомен, контролируемый издателем библиотеки, в качестве Maven groupId. Это обычная схема именования для groupId. Например, для своих библиотек я использую org.cicirello в качестве groupId на Maven Central для всех моих библиотек. Я также могу, если захочу, использовать любой org.cicirello.SUBDOMAIN на Maven Central, поскольку я проверил право собственности на сам домен.

В JitPack вместо этого groupId основан на комбинации git-хоста (например, GitHub) и userid на этом git-хосте. Это происходит потому, что JitPack создает артефакты по требованию из исходного репозитория в первый раз, когда кто-то импортирует определенную версию с помощью git-тега, ветки, хэша коммита и т.д. В предыдущем посте этой серии есть более подробное объяснение того, как работает JitPack.

Для согласованности с артефактами, опубликованными на Maven Central или где-либо еще, было бы неплохо использовать подход обратного домена и в JitPack. И оказалось, что JitPack поддерживает это. Подробности можно найти в документации по JitPack. Для этого вы настраиваете TXT-запись у вашего DNS-провайдера, сопоставляя git.yourdomain.extension с https://github.com/USERNAME. Когда вы или кто-то другой ссылается на вашу библиотеку через groupId, равный вашему обратному домену, JitPack проверяет наличие такой TXT-записи у вашего DNS-провайдера, обнаруживая соответствующий репозиторий GitHub (или другой git-хост). По сути, это создает псевдоним на JitPack.

В результате через JitPack ваша библиотека может быть импортирована либо через стандартный подход JitPack к имени git-хоста / репозитория, либо через ваш обратный домен. Пример для одной из моих библиотек выглядит следующим образом.

Стандартный способ импорта из JitPack включает в себя добавление следующего в pom.xml, чтобы использовать его в качестве зависимости:

<dependency>
  <groupId>com.github.cicirello</groupId>
  <artifactId>chips-n-salsa</artifactId>
  <version>5.2.0</version>
</dependency>

Но как только домен настроен, работает и следующее.

<dependency>
  <groupId>org.cicirello</groupId>
  <artifactId>chips-n-salsa</artifactId>
  <version>5.2.0</version>
</dependency>

Последний вариант предпочтительнее, поскольку он соответствует спецификации зависимостей, требуемой при импорте из Maven Central. Удобно, что имя репозитория для этой библиотеки совпадает с artifactId, который я уже использовал в Maven Central, поскольку JitPack не предоставляет механизма для использования artifactId, отличающегося от имени репозитория.

Однако обратите внимание, что JitPack ведет себя странно: каждый из вышеперечисленных случаев рассматривается как отдельный. Первый раз, когда артефакт импортируется с помощью com.github.cicirello потребует сборки, и первый раз, когда кто-либо импортирует с помощью org.cicirello также потребует сборки. Таким образом, это не совсем создание псевдонима. Оба варианта будут собирать библиотеку, создавая jar-файлы с идентичным содержимым, но с разными именами jar-файлов, как если бы это были разные артефакты.

Как выполнить сборку заранее с настроенным groupId

Хотя JitPack предназначен для сборки артефактов по требованию, после сборки последующие запросы от вас или других людей на ту же версию больше не требуют сборки. Таким образом, хотя первый импорт страдает от задержки ожидания сборки, последующие импорты происходят так же быстро, как и в большинстве других Maven-репозиториев (примечание: я не засекал время, но я не вижу никакой различимой человеком разницы после сборки).

Если вы просто используете комбинацию git host / username для groupId, то JitPack предоставляет webhook, который вы можете настроить на GitHub или Bitbucket. Подробности о веб-крючках JitPacks можно найти в документации JitPack. После настройки каждый push в ветку по умолчанию (например, main) будет использовать вебхук, заставляя JitPack собирать текущий коммит. Таким образом, первый фактический импорт не будет страдать от задержки в ожидании сборки. Однако, как мы видели в предыдущем разделе, JitPack рассматривает пользовательский обратный домен как отдельный groupId от версии, основанной на git-хосте. Поэтому эти вебхуки не будут выполнять опережающую сборку для пользовательского обратного домена groupId. Кроме того, похоже, что эта функция поддерживает только GitHub и Bitbucket, так что если ваш проект размещен в другом месте, эти веб-крючки могут оказаться неприемлемыми.

Хитрость 1:

После каждого push в ветку по умолчанию используйте curl, чтобы обмануть JitPack и заставить его думать, что мы импортируем последний снимок репозитория, но используем ваш обратный домен. JitPack начнет сборку. На самом деле вам не нужны артефакты. Вы просто хотите начать сборку. Поэтому используйте curl с таймаутом, чтобы избежать ожидания сборки.

Вот пример, предполагающий, что ваш обратный домен com.example, с именем репозитория (и, следовательно, artifactId) REPOSITORY, и веткой по умолчанию main:

curl -s -m 30 https://jitpack.io/com/example/REPOSITORY/main-SNAPSHOT/

-m 30 выше — это 30-секундный тайм-аут. Я использовал несколько проб и ошибок при выборе длительности тайм-аута. Я начал с 1 секунды, что часто не приводило к запуску сборки. Затем я попробовал 10 секунд, которые часто запускали сборку, но иногда не запускали сборку на JitPack. 30 секунд, похоже, постоянно работают, чтобы запустить сборку.

Имейте в виду, что вышеупомянутый curl фактически «провалится» с ненулевым кодом ошибки после того, как завершится (если только ваш проект не собирается менее чем за 30 секунд). Не беспокойтесь об этом. Вам все равно не нужны артефакты сейчас. И даже если бы они вам были нужны, приведенный выше curl не отдаст их вам. Он просто откроет страницу, на которой они перечислены. Вы просто хотите, чтобы артефакты были доступны позже. Если предположить, что вы используете вышеприведенный сценарий в скрипте, вам может понадобиться что-то вроде следующего, чтобы избежать сбоя всей работы при завершении работы curl.

curl -s -m 30 https://jitpack.io/com/example/REPOSITORY/main-SNAPSHOT/ || true

Хитрость 2:

В каждом релизе вашей библиотеки используйте curl, чтобы обмануть JitPack и заставить его думать, что мы импортируем последний релиз, используя соответствующий номер версии. Если тег release v1.2.3, то выполните следующий curl, убрав «v» (для согласованности с другими репозиториями Maven). Это все еще предполагает, что ваш обратный домен com.example, с именем репозитория REPOSITORY, поэтому просто измените это для вашего реального обратного домена и имени репозитория.

curl -s -m 30 https://jitpack.io/com/example/REPOSITORY/1.2.3/ || true

URL в этом примере — это место, где будут храниться артефакты вашего релиза после его создания. Запрос URL-адреса этого каталога запускает сборку.

Рабочие процессы GitHub Actions для опережающих сборок JitPack

Если ваш проект находится на GitHub, вы можете поместить все вышеперечисленное в один или несколько рабочих процессов GitHub Actions, чтобы автоматизировать это. Вот как это делаю я.

При отправке в ветку по умолчанию:

При каждом пуше в ветку по умолчанию (в данном примере предполагается main) я использую следующий рабочий процесс (просто заполните детали вашего обратного домена и имя ветки по умолчанию, где это уместно). Этот пример рабочего процесса делает те же предположения, что и предыдущий раздел (например, что ваш обратный домен com.example и т.д.). Живой пример смотрите в jitpack-build.yml в одном из моих репозиториев.

name: jitpack-build

on:
  push:
    branches: [ main ]

jobs:
  jitpack:

    runs-on: ubuntu-latest

    steps:

    - name: Request main-SNAPSHOT from JitPack
      run: |
        # timeout in 30 seconds to avoid waiting for build
        curl -s -m 30 https://jitpack.io/com/example/REPOSITORY/main-SNAPSHOT/ || true

В большинстве рабочих процессов GitHub обычно требуется шаг actions/checkout, но здесь он нам не нужен, поскольку мы ничего не делаем с кодом из нашего репозитория.

О релизах:

Я использую события релизов GitHub для запуска рабочего процесса, который собирает и развертывает артефакты в Maven Central, а также в GitHub Packages. В конце этого рабочего процесса я добавил шаг для обработки опережающих сборок на JitPack. Ниже приведена сокращенная версия этого рабочего процесса, которая показывает только то, что необходимо для опережающих сборок на JitPack. Он запускается при создании релиза. На первом этапе удаляется v из тега релиза. После этого мы используем трюк curl.

name: Release

on:
  release:
    types: [created]

jobs:
  publish:

    runs-on: ubuntu-latest

    steps:
    - name: Get the release version, removing the v from the tag
      id: get_version
      run: echo ::set-output name=VERSION::${GITHUB_REF/refs/tags/v/}

    - name: Request release from JitPack to trigger build
      run: |
        JITPACK_URL="https://jitpack.io/com/example/REPOSITORY/${{ steps.get_version.outputs.VERSION }}/"
        # timeout in 30 seconds to avoid waiting for build
        curl -s -m 30 ${JITPACK_URL} || true

Полный рабочий процесс моего проекта можно найти здесь, если вы хотите посмотреть, как я включил это в более крупный рабочий процесс, который собирает и развертывает Maven Central и пакеты GitHub. Этот рабочий процесс находится в следующем репозитории:

cicirello / Chips-n-Salsa

Java-библиотека настраиваемых, гибридизируемых, итеративных, параллельных, стохастических и самоадаптивных алгоритмов локального поиска

Chips-n-Salsa — Java-библиотека настраиваемых, гибридизируемых, итеративных, параллельных, стохастических и самоадаптивных алгоритмов локального поиска.

Copyright (C) 2002-2022 Vincent A. Cicirello.

Веб-сайт: https://chips-n-salsa.cicirello.org/

Документация по API: https://chips-n-salsa.cicirello.org/api/

Публикации О библиотеке
Пакеты и релизы
Статус сборки
Покрытие тестов JaCoCo
Безопасность
DOI
Лицензия
Поддержка

Как цитировать

Если вы используете эту библиотеку в своих исследованиях, пожалуйста, ссылайтесь на следующую работу:

Cicirello, V. A., (2020). Chips-n-Salsa: Java-библиотека настраиваемых, гибридизируемых, итеративных, параллельных, стохастических и самоадаптивных алгоритмов локального поиска. Journal of Open Source Software, 5(52), 2448, https://doi.org/10.21105/joss.02448 .

Обзор

Chips-n-Salsa — это Java-библиотека настраиваемых, гибридизируемых, итеративных, параллельных, стохастических и самоадаптивных алгоритмов локального поиска. Библиотека включает реализации нескольких стохастических алгоритмов локального поиска, включая имитационный отжиг, альпинистские алгоритмы, а также конструктивные алгоритмы поиска, такие как стохастическая выборка. Chips-n-Salsa теперь также включает генетические алгоритмы, а также эволюционные алгоритмы в целом. Библиотека очень широко поддерживает симулированные…

Посмотреть на GitHub

Где вы можете меня найти

В Интернете:

Винсент А. Чичирелло — профессор компьютерных наук

Винсент А. Чичирелло — профессор компьютерных наук в Стоктонском университете — исследователь в области искусственного интеллекта, эволюционных вычислений, роевого интеллекта и вычислительного интеллекта, доктор философии по робототехнике в Университете Карнеги-Меллон. Он является старшим членом ACM, старшим членом IEEE, пожизненным членом AAAI, заслуженным членом EAI и членом SIAM.

cicirello.org

Следите за мной на DEV:

Винсент А. Чичирелло

Исследователь и преподаватель в области А.И., алгоритмов, эволюционных вычислений, машинного обучения и роевого интеллекта.

Следите за мной на GitHub:

cicirello / cicirello

Мой профиль на GitHub

Vincent A Cicirello

Сайты, где вы можете найти меня или мои работы
Веб и социальные сети
Разработка программного обеспечения
Публикации

Если вы хотите сгенерировать эквивалент вышеуказанного для своего профиля на GitHub, ознакомьтесь с действием cicirello/user-statisticianGitHub.

Посмотреть на GitHub