Continious Integration на примере мода

Continious Integration на примере мода

Здравствуйте всем привет всем. Хотелось бы рассказать про использование такой прекрасной штуки как Github Actions. В общем-то, это такая фича Github, которая позволяет в свою разработку внедрить CI/CD. Зачем же это нужно? Допустим, вы пишете серьезный мод/библиотеку. Чтобы каждый перед коммитом/релизом не запускать тесты (если, конечно, таковые есть), не компилить файл и не загружать его в Releases, в репозиторий Maven/Curse, вы делаете конфиг, который при определенных условиях запускает actions, а те в свою очередь делают то, что вам нужно - билдят, публикуют куда-то, запускают скрипты и т.д; все ограничивается только вашей фантазией и нуждами.

Так вот, чтобы заюзать эту фичу, потребуется лишь репозиторий на github.
Итак, первым шагом мы создадим .github/workflows/ там, где находится git репозиторий, и внутри release.yml:
Bash:
$ mkdir -p .github/workflows
$ touch .github/workflows/release.yml

release.yml - это как раз наш workflow. Можно создать больше одного. Например, если вы хотите, чтобы один вызывался после коммита, а другой - при пулл реквесте. Они выполняются параллельно друг другу, поэтому придется пошаманить, если нужна синхронная работа. Если кому-то это будет интересно, то потом добавлю эту инфу.

После создания файла его нужно заполнить. Вот так он выглядит у меня:
JSON:
name: release
on:
  push:
    tags:
      - 'v*'
jobs:
  build:
    name: Create Release
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@master

      - name: Set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8

      - name: Grant execute permission for gradlew
        run: chmod +x gradlew

      - name: Build with Gradle
        run: ./gradlew build

      - name: Create Release
        id: create_release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ github.ref }}
          release_name: Release ${{ github.ref }}
          draft: false
          prerelease: false

      - name: Upload Release Asset
        id: upload-release-asset
        uses: actions/upload-release-asset@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          upload_url: ${{ steps.create_release.outputs.upload_url }}
          asset_path: ./build/libs/mc-properties.jar
          asset_name: mc-properties.jar
          asset_content_type: application/java-archive
Как можно заметить, файл представляет из себя обычный yaml.
name - просто название workflow, отображается на github.
В on мы указываем события, при котором срабатывают дальнейшие таски. В данном случае это push тэга, который начинается с v (v.1.0.0, etc).
Далее идут таски наподобие тех, что есть в gradle. Каждый таск имеет свое имя, систему сборки, шаги.

Итак, теперь по шагам:
  1. Клонирование репозитория на удаленную систему. Использует стандартный гитхабовский uses, который определяет, что будет происходить.
  2. Далее идет установка JDK версии 1.8
  3. Тут идет стандартная команда, которая выдает права на исполнение скрипта сборки (он, кстати, должен лежать у вас в репозитории, если вы его не удаляли после установки mdk)
  4. Собственно сама сборка
  5. Создается релиз в одноименной вкладке. В env указывается токен, который нужен для работы с api и создания релиза и который github создает каждый раз при запуске сборки (т.е. его не нужно создавать самому). После сборки он будет отозван, так что все безопасно. В with-блоке указываются параметры, название которых говорит за себя. ${{...}} - это шаблоны github'a, вместо них будут подставлены строки. Подробнее о том, какие есть шаблоны, можно почитать в офф. документации.
  6. Загружаем в созданный релиз собранный ранее jar. В asset_path указываем путь, где после сборки лежит файл (build/libs обычно), указываем его имя и mime-type файла.
  7. PROFIT!

Итак, теперь, после создания workflow, мы коммитим и пушим в удаленный репозиторий. С этого момента, при последующих коммитах с тэгом будет запускаться workflow и гитхаб будет прогонять все эти таски. Тэг создается так:
Bash:
$ git tag v1.0.0
$ git push origin --tags
Само собой на момент создания тэга коммит, который нужно билдить, должен быть "вытолкнут" в удаленный репозиторий. В принципе, можно сделать и так:
Bash:
$ git add .
$ git commit ...
$ git tag v1.0.0
$ git push origin master --tags
Делайте на свое усмотрение, разницы никакой.

Собственно всё! Теперь, после коммита с тэгом, я могу спокойно использовать эту библиотеку в своем проекте через JitPack. Все удобно и гибко!
В дальнейшем можно будет расширять свой функционал через другие actions, которые предоставляет гитхаб и сообщество, а также через всевозможные скрипты. Например, есть скрипт для публикации в maven репозиторий и многое другое.


Существуют также и Jenkins, travis-ci, circleci и еще куча других сервисов. Однако они не настолько просты как GH Actions и предназначены больше для крупных проектов. Вряд ли они вам понадобятся в mc.
Исправления принимаются и очень даже ожидаются, т.к. я еле написал это :unsure:
Автор
CumingSoon
Просмотры
634
Первый выпуск
Обновление
Оценка
0.00 звёзд 0 оценок

Другие ресурсы пользователя CumingSoon

Сверху