Я использую GitHub Actions для управления рабочими процессами CI/CD для всех своих проектов. В этом посте я объясню свой рабочий процесс развертывания для проектов Java. Он запускается после выпуска GitHub. Он развертывает артефакты как в репозитории Maven Central, так и в пакетах GitHub. Он запускает предварительную сборку на JitPack. И он использует интерфейс командной строки GitHub для загрузки артефактов в выпуск GitHub.

Этот пост предполагает знание настройки вашего Maven pom.xml по мере необходимости для развертывания в нескольких репозиториях Maven с использованием профилей Maven для каждого из репозиториев, как описано в моем предыдущем посте:

В этом посте также используется прием, описанный в другом предыдущем посте, для запуска упреждающей сборки на JitPack при использовании обратного домена Maven. groupIdа не JitPack по умолчанию для сборок по требованию:

Мой рабочий процесс, который я объясняю в этом посте, основан на выпусках GitHub. Создание выпуска GitHub — это событие, которое запускает рабочий процесс, и рабочий процесс прикрепляет JAR-файлы к выпуску в качестве одного из своих шагов. Для получения дополнительной информации о выпусках GitHub и других вещах, которые вы можете с ними делать, см. замечательный пост @mishmanners, опубликованный ранее сегодня:

Оглавление:


Рабочий процесс шаг за шагом

Я собираюсь пройти весь рабочий процесс от начала до конца.


При выпуске

Рабочие процессы GitHub начинаются с событий, которые запускают его. В этом случае рабочий процесс запускается при создании выпуска.

name: Maven Package

on:
  release:
    types: [created]
Войти в полноэкранный режим

Выйти из полноэкранного режима


Настроить работу

Мой рабочий процесс развертывания состоит из одного задания и работает в Ubuntu. Я определяю переменную среды artifact_name с Знатоком artifactId который используется на нескольких этапах рабочего процесса. В этом нет строгой необходимости, но я использую один и тот же рабочий процесс в нескольких репозиториях, что упрощает настройку для другого репозитория. У меня не было времени объединиться в многоразовый рабочий процесс, так как они были недавно представлены GitHub.

jobs:
  publish:

    runs-on: ubuntu-latest

    env:
      artifact_name: chips-n-salsa
Войти в полноэкранный режим

Выйти из полноэкранного режима


Проверить репозиторий

Этот шаг не требует пояснений и находится в начале большинства рабочих процессов GitHub.

    steps:
    - uses: actions/checkout@v3
Войти в полноэкранный режим

Выйти из полноэкранного режима


Обработать тег выпуска

Я использую общепринятое соглашение о выпуске тегов, которое начинается с v затем следует семантическая версия. Например, v1.2.3. Однако версии Maven не включают v. Таким образом, этот шаг получает тег выпуска, удаляет v из него и устанавливает выход шага с именем VERSION которые можно использовать на более поздних этапах рабочего процесса.

    - name: Get the release version
      id: get_version
      run: echo "VERSION=${GITHUB_REF/refs\/tags\/v/}" >> $GITHUB_OUTPUT
Войти в полноэкранный режим

Выйти из полноэкранного режима

Для получения дополнительной информации о настройке выходных данных из шагов рабочего процесса см. мой предыдущий пост DEV на прошлой неделе:


Вставьте релизную версию в pom.xml

Нам нужно <version></version> внутри pom.xml чтобы соответствовать версии, которую мы развертываем. Не забываем отредактировать pom.xml вручную подвержено ошибкам и легко забывается. Вместо этого я ввожу версию выпуска во время рабочего процесса развертывания, используя mvn versions:set. Эта команда фактически изменяет pom.xml. Если бы я хотел pom.xml в репозитории, чтобы быть в курсе последней версии, я мог бы добавить шаг для фиксации изменения. Тем не менее, я оставляю его как версию моментального снимка в репозитории (например, <version>6-SNAPSHOT</version>), чтобы не ввести в заблуждение любого, кто может строить из исходного кода, поверить в то, что он создал релизную версию.

Шаг для внедрения версии выпуска в pom.xml использует вывод из предыдущего шага выше и mvn versions:set команда следующим образом:

    - name: Update package version
      run: mvn versions:set -DnewVersion=${{ steps.get_version.outputs.VERSION }}
Войти в полноэкранный режим

Выйти из полноэкранного режима


Настройка Java и развертывание в Maven Central

Эта пара шагов сначала использует setup-java GitHub Action для настройки того, что нам нужно для развертывания в репозитории Maven Central. В основном это описано в документации GitHub Actions.

Второй из этой пары шагов выполняется mvn deploy -PossrhDeploy. Параметр командной строки -PossrhDeploy активирует профиль Maven с идентификатором ossrhDeploy которые я определил в pom.xml где я настроил все необходимое для развертывания в Maven Central. См. мою предыдущую публикацию об использовании профилей Maven, чтобы узнать, как можно использовать профили Maven для выборочной активации конфигурации, а также конкретный пример настройки Maven для развертывания в нескольких репозиториях.

    - name: Set up JDK 17 for deploy to OSSRH
      uses: actions/setup-java@v3
      with:
        distribution: 'adopt'
        java-version: '17'
        server-id: ossrh 
        server-username: MAVEN_USERNAME
        server-password: MAVEN_CENTRAL_TOKEN
        gpg-private-key: ${{ secrets.MAVEN_GPG_PRIVATE_KEY }}
        gpg-passphrase: MAVEN_GPG_PASSPHRASE

    - name: Publish to Apache Maven Central
      run: mvn deploy -PossrhDeploy
      env:
        MAVEN_USERNAME: ${{ secrets.MAVEN_CENTRAL_USERNAME }}
        MAVEN_CENTRAL_TOKEN: ${{ secrets.MAVEN_CENTRAL_TOKEN }}
        MAVEN_GPG_PASSPHRASE: ${{ secrets.MAVEN_GPG_PASSPHRASE }}
Войти в полноэкранный режим

Выйти из полноэкранного режима


Настройка Java и развертывание в GitHub Packages

Эта пара шагов аналогична предыдущей паре шагов, но на этот раз для развертывания в GitHub Packages. Первый шаг ниже использует setup-java, но на этот раз для развертывания в GitHub Packages. Это проще, чем то, что необходимо для развертывания в Maven Central. Второй шаг ниже выполняет фактическое развертывание с использованием: mvn deploy -PgithubDeploy. Как и выше, я настроил <distributionManagement><repository> в профиле Maven с идентификатором githubDeployкоторый активируется параметром командной строки -PgithubDeploy.

    - name: Set up JDK 17 for deploy to github packages
      uses: actions/setup-java@v3
      with:
        distribution: 'adopt'
        java-version: '17'
        server-id: github 

    - name: Publish to GitHub Packages Apache Maven
      run: mvn deploy -PgithubDeploy
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 
Войти в полноэкранный режим

Выйти из полноэкранного режима


Используйте интерфейс командной строки GitHub для загрузки файлов JAR в качестве ресурсов выпуска.

Я также загружаю различные jar-файлы, созданные во время сборки, в качестве ресурсов для выпуска. Для этого я использую интерфейс командной строки GitHub, который всегда доступен для использования во время выполнения рабочего процесса GitHub. В частности, я использую gh release upload команда, для которой требуется тег релиза, а также файл, который вы загружаете. Проект, на котором он основан, создает 4 файла jar, в том числе обычные 3 (jar библиотеки, jar исходников и jar javadocs), а четвертый jar — это библиотека, включающая все зависимости. Поскольку я использую Maven, артефакты создаются в target каталог во время сборки, и я использую переменную среды, которую я установил в самом начале с Maven artifactId и результат предыдущего шага с Maven <version> (отпустить тег без v) для формирования имен файлов.

    - name: Upload jar files to release as release assets
      run: |
        TAG=${GITHUB_REF/refs\/tags\//}
        gh release upload ${TAG} target/${{ env.artifact_name }}-${{ steps.get_version.outputs.VERSION }}.jar
        gh release upload ${TAG} target/${{ env.artifact_name }}-${{ steps.get_version.outputs.VERSION }}-sources.jar
        gh release upload ${TAG} target/${{ env.artifact_name }}-${{ steps.get_version.outputs.VERSION }}-javadoc.jar
        gh release upload ${TAG} target/${{ env.artifact_name }}-${{ steps.get_version.outputs.VERSION }}-jar-with-dependencies.jar 
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Войти в полноэкранный режим

Выйти из полноэкранного режима


Опережающая сборка релиза JitPack

Некоторое время назад в посте я объяснил, как заставить JitPack собираться заблаговременно, используя групповой идентификатор вашего обратного домена. JitPack обычно создается по запросу при первом запросе артефакта. Это делается из репозитория GitHub артефакта. Таким образом, когда кто-то впервые импортирует версию вашей библиотеки из JitPack, его сборка будет отложена на время ожидания сборки вашей библиотеки. Мы можем устранить эту задержку с помощью простого завитка, как показано на шаге ниже. Тайм-аут необходим, потому что сейчас вам не нужно ничего скачивать. Вы просто хотите, чтобы JitPack думал, что вы хотите загрузить артефакты. Используя тайм-аут, вы избегаете траты циклов на исполнителя вашего рабочего процесса.

ВАЖНЫЙ: Если вы используете этот трюк в своем рабочем процессе, убедитесь, что вы изменили org/cicirello на любой обратный домен, который вы настроили с помощью JitPack в качестве своего groupId.

    - name: Request release from JitPack to trigger build
      run: |
        JITPACK_URL=" env.artifact_name }}/${{ steps.get_version.outputs.VERSION }}/maven-metadata.xml"
        # timeout in 30 seconds to avoid waiting for build
        curl -s -m 30 ${JITPACK_URL} || true
Войти в полноэкранный режим

Выйти из полноэкранного режима


Полный рабочий процесс

Вот мой полный рабочий процесс развертывания Java.

name: Maven Package

on:
  release:
    types: [created]

jobs:
  publish:

    runs-on: ubuntu-latest

    env:
      artifact_name: chips-n-salsa

    steps:
    - uses: actions/checkout@v3

    - name: Get the release version
      id: get_version
      run: echo "VERSION=${GITHUB_REF/refs\/tags\/v/}" >> $GITHUB_OUTPUT

    - name: Update package version
      run: mvn versions:set -DnewVersion=${{ steps.get_version.outputs.VERSION }}

    - name: Set up JDK 17 for deploy to OSSRH
      uses: actions/setup-java@v3
      with:
        distribution: 'adopt'
        java-version: '17'
        server-id: ossrh 
        server-username: MAVEN_USERNAME
        server-password: MAVEN_CENTRAL_TOKEN
        gpg-private-key: ${{ secrets.MAVEN_GPG_PRIVATE_KEY }}
        gpg-passphrase: MAVEN_GPG_PASSPHRASE

    - name: Publish to Apache Maven Central
      run: mvn deploy -PossrhDeploy
      env:
        MAVEN_USERNAME: ${{ secrets.MAVEN_CENTRAL_USERNAME }}
        MAVEN_CENTRAL_TOKEN: ${{ secrets.MAVEN_CENTRAL_TOKEN }}
        MAVEN_GPG_PASSPHRASE: ${{ secrets.MAVEN_GPG_PASSPHRASE }}

    - name: Set up JDK 17 for deploy to github packages
      uses: actions/setup-java@v3
      with:
        distribution: 'adopt'
        java-version: '17'
        server-id: github 

    - name: Publish to GitHub Packages Apache Maven
      run: mvn deploy -PgithubDeploy
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 

    - name: Upload jar files to release as release assets
      run: |
        TAG=${GITHUB_REF/refs\/tags\//}
        gh release upload ${TAG} target/${{ env.artifact_name }}-${{ steps.get_version.outputs.VERSION }}.jar
        gh release upload ${TAG} target/${{ env.artifact_name }}-${{ steps.get_version.outputs.VERSION }}-sources.jar
        gh release upload ${TAG} target/${{ env.artifact_name }}-${{ steps.get_version.outputs.VERSION }}-javadoc.jar
        gh release upload ${TAG} target/${{ env.artifact_name }}-${{ steps.get_version.outputs.VERSION }}-jar-with-dependencies.jar 
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

    - name: Request release from JitPack to trigger build
      run: |
        JITPACK_URL=" env.artifact_name }}/${{ steps.get_version.outputs.VERSION }}/maven-metadata.xml"
        # timeout in 30 seconds to avoid waiting for build
        curl -s -m 30 ${JITPACK_URL} || true
Войти в полноэкранный режим

Выйти из полноэкранного режима


Живой пример

Чтобы увидеть живой пример, обратитесь к maven-publish.yml рабочий процесс одного из моих проектов. Вот репозиторий GitHub:

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

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

Авторское право (С) 2002-2022 Винсент А. Чичирелло.

Веб-сайт:

Документация по API: API/

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

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

Чичирелло, Вирджиния, (2020). Chips-n-Salsa: Java-библиотека настраиваемых, гибридизируемых, итеративных, параллельных, стохастических и самоадаптирующихся алгоритмов локального поиска. Журнал программного обеспечения с открытым исходным кодом5(52), 2448, .

Обзор

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


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

Подписывайтесь на меня здесь, на DEV:

изображение чичирелло

Подпишитесь на меня на GitHub:

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

Моя библиометрия

Моя активность на GitHub

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

Или посетите мой сайт:

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

фавикон
cicirello.org