Автоматические релизы GitHub через теги и Actions

Быстрые ссылки

• Using Tagged Releases

• Setting Up GitHub Actions

ALT: Баннер GitHub с логотипом, иллюстрация для страницы релизов

Что такое релизы по тегам и зачем они нужны

ALT: Снимок экрана страницы релизов GitHub с примерами тегов и артефактов

Теги — встроенная функция Git, теги фиксируют конкретный коммит и не двигаются дальше. GitHub расширяет теги объектом Releases, где можно хранить бинарники (артефакты) и сопроводительные changelog’и. Обычно используют семантическую нумерацию версий Major.Minor.Patch.

Теги удобно подключать к автоматизации: когда вы пушите тег в репозиторий, workflow может автоматически собрать проект, создать релиз и загрузить бинарники на страницу релизов.

Краткое определение: тег — фиксированная ссылка на коммит; релиз — объект GitHub с метаданными и файлами, привязанный к тегу.

Настройка GitHub Actions для публикации релизов

Перед добавлением шагов публикации убедитесь, что у вас уже есть рабочий сборочный pipeline и что он генерирует артефакты. Идея — не отлаживать сборку и публикацию одновременно. Добавление публикации релизов делается после того, как сборка стабильно работает.

1. Измените секцию “on” в workflow, чтобы реакция происходила на создание тегов. Например, чтобы реагировать на все теги, используйте wildcard:

on:
  push:
    tags:
      - "*"

2. В конце workflow, после сборки и подготовки артефактов, создайте объект Release и затем загрузите артефакты по полученному upload_url.

3. Выполняйте шаги создания Release и загрузки артефактов только если workflow запущен из тега — проверка делается по значению github.ref.

Простейшая проверка в шагах:

if: startsWith(github.ref, 'refs/tags/')

Важно: github.ref содержит имя ветки или тега, который вызвал workflow.

Пример шага создания Release

Ниже — пример шага, который создаёт объект Release. Токен GITHUB_TOKEN предоставляется автоматически в среде Actions и не требует ручного создания.

- name: Create Release
  if: startsWith(github.ref, 'refs/tags/')
  uses: actions/create-release@v1
  id: create_release
  with:
    draft: false
    prerelease: false
    release_name: ${{ github.ref }}
    tag_name: ${{ github.ref }}
    body_path: CHANGELOG.md
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Обратите внимание: файл CHANGELOG.md должен существовать в репозитории — он используется как тело релиза и обязателен для корректного выполнения шага, если вы указываете body_path.

Есть инструменты, которые генерируют CHANGELOG автоматически на основе сообщений коммитов, но большинство команд используют собственную методологию управления changelog.

Пример шага загрузки артефакта

После создания релиза используйте upload-release-asset для загрузки файлов. В with указываются upload_url (из вывода предыдущего шага), путь к файлу и имя ресурса, отображаемое на странице релиза.

- name: Upload Release
  if: startsWith(github.ref, 'refs/tags/')
  uses: actions/upload-release-asset@v1
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  with:
    upload_url: ${{ steps.create_release.outputs.upload_url }}
    asset_path: Oxide.Ext.Sanctuary/bin/Release/net48/Oxide.Ext.Sanctuary.dll
    asset_name: Oxide.Ext.Sanctuary.dll
    asset_content_type: application/octet-stream

ALT: Снимок экрана шага Action в UI GitHub, показывающий загрузку релизного артефакта

Тип контента в asset_content_type обычно application/octet-stream для бинарных файлов, DLL или исполняемых файлов. Для ZIP/текстовых файлов укажите соответствующий MIME-тип — это влияет только на метаданные и способ отображения в UI.

После коммита изменений в workflow создайте тег и запушьте его в GitHub. Должен запуститься новый прогон workflow, инициированный тегом, а не веткой master/main.

ALT: Снимок экрана списка запусков workflow в GitHub Actions, отмечен запуск от тега

Когда workflow завершится успешно, объект релиза появится в боковой панели репозитория GitHub.

Мини-методология: шаги от тега до релиза

• Создайте тег локально (git tag v1.2.3) или через CI при мёрдже в определённую ветку.
• Push тега: git push origin v1.2.3
• Workflow: сборка артефактов → тесты → packaging
• Если сборка успешна и github.ref — тег, создаётся Release и загружаются артефакты
• GitHub отображает релиз с changelog из CHANGELOG.md или body

Шаблон полного workflow (упрощённый пример)

name: Build and Release
on:
  push:
    tags:
      - "*"

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '7.0.x'
      - name: Build
        run: dotnet build --configuration Release
      - name: Run tests
        run: dotnet test --no-build --verbosity normal
      - name: Pack artifacts
        run: dotnet publish -c Release -o ./out
      - name: Create Release
        if: startsWith(github.ref, 'refs/tags/')
        uses: actions/create-release@v1
        id: create_release
        with:
          tag_name: ${{ github.ref }}
          release_name: ${{ github.ref }}
          body_path: CHANGELOG.md
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: Upload Release Asset
        if: startsWith(github.ref, 'refs/tags/')
        uses: actions/upload-release-asset@v1
        with:
          upload_url: ${{ steps.create_release.outputs.upload_url }}
          asset_path: ./out/myapp.zip
          asset_name: myapp.zip
          asset_content_type: application/zip
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Чек-листы по ролям

Разработчик:

• Убедиться в корректности семантического тега.
• Добавить CHANGELOG.md или убедиться, что генератор changelog работает.
• Тестировать локально сборку и упаковку.

DevOps/CI инженер:

• Настроить workflow, переменные окружения и секреты.
• Проверить, что GITHUB_TOKEN доступен и имеет права на создание релизов.
• Настроить уведомления о неуспехе pipeline.

Руководитель проекта:

• Утверждать правила версионирования и политику prerelease/draft.
• Контролировать, кто имеет право пушить теги в репозиторий.

Критерии приёмки

• При пуше тега запускается workflow.
• После завершения успешного workflow в репозитории отображается релиз с указанным тегом.
• В релизе присутствуют все ожидаемые артефакты и корректный CHANGELOG.
• Вся автоматизация работает без ручного вмешательства (кроме публикации тега).

Когда этот подход не подходит

• Если вам нужно контролировать публикацию вручную (без автоматического выпуска при пуше тега). В этом случае используйте Draft-релизы и ручную публикацию.
• Если релизы должны проходить дополнительную процедуру одобрения (manual approval), добавьте шаги типа environment protection или manual review перед созданием релиза.
• Для крупных бинарных дистрибуций с ограничениями хранения/политиками распространения (например, подписанные пакеты, приватные артефакты) могут понадобиться другие хранилища (S3, Artifactory).

Риски и смягчения

• Риск: случайный пуш тега и публикация несобранного кода. Смягчение: защита веток, проверка CI перед разрешением пуша тегов, использование правил доступа.
• Риск: утечка секретов в артефактах. Смягчение: не включать секреты в артефакты, проверять сборку на присутствие чувствительных данных.
• Риск: нехватка лимитов API при массовых релизах. Смягчение: ограничить частоту автоматических релизов, использовать backoff/retry.

Базовый словарь (1‑строчник)

• Tag: фиксированная ссылка на коммит в Git.
• Release: объект GitHub с метаданными и загружаемыми файлами, привязанный к тегу.
• GITHUB_TOKEN: встроенный секрет Actions для доступа к API репозитория.
• upload_url: URL, получаемый после создания Release, куда загружаются файлы.

Короткое объявление для команды (100–200 слов)

Начиная с текущей ветки мы автоматически публикуем релизы на GitHub при создании тегов. Пушьте семантические теги (например, v1.2.3) — workflow соберёт проект, прогонит тесты и, в случае успеха, создаст релиз и загрузит артефакты. CHANGELOG.md используется как текст релиза; пожалуйста, обновляйте его перед созданием тега. Если нужна ручная модерация релиза — используйте draft/release approval. Для вопросов по настройке CI или политике тегирования обращайтесь к команде DevOps.

Итог

Автоматизация релизов через теги и GitHub Actions позволяет упростить доставку версий пользователям, стандартизировать artefact-менеджмент и минимизировать ручные ошибки. Настройка состоит из трёх ключевых частей: реагирование на пуш тегов, создание объекта Release и загрузка артефактов. Обязательно контролируйте CHANGELOG.md и права на пуш тегов.

Важно: тестируйте изменения workflow в отдельном тестовом репозитории или на тестовых тегах перед применением в боевом репозитории.