Деплой по тегу и релизу

Катим на прод не на каждый коммит, а по осознанному релизному тегу.

Тег вида v1.4.0 — удобный «спусковой крючок» для деплоя: вы сами решаете, какой коммит станет релизом.

Триггер по тегам

Workflow можно запускать только при пуше тегов, подходящих под маску:

on:
  push:
    tags:
      - "v*"          # любой тег, начинающийся с v: v1.0.0, v2.3.1

Теперь обычные пуши в ветки деплой не запускают, а команда git tag v1.4.0 && git push origin v1.4.0 — запускает.

Триггер по релизу

Если вы оформляете релизы через интерфейс GitHub, используйте событие release:

on:
  release:
    types: [published]    # когда релиз опубликован

Тогда деплой стартует в момент публикации релиза, а имя тега доступно как ${{ github.event.release.tag_name }}.

Пример: деплой на сервер по SSH

Классическая выкладка — зайти на сервер по SSH и обновить приложение. Приватный ключ держим в секретах:

name: Deploy on tag
on:
  push:
    tags: ["v*"]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4

      - name: Подготовить SSH-ключ
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_ed25519
          chmod 600 ~/.ssh/id_ed25519
          ssh-keyscan -H "${{ vars.SERVER_HOST }}" >> ~/.ssh/known_hosts

      - name: Выкатить релиз
        run: |
          ssh -i ~/.ssh/id_ed25519 deploy@${{ vars.SERVER_HOST }} "
            cd /srv/app &&
            git fetch --tags &&
            git checkout ${{ github.ref_name }} &&
            docker compose up -d --build
          "

Здесь приватный ключ — секрет (SSH_PRIVATE_KEY), а адрес сервера — открытая переменная (SERVER_HOST). ssh-keyscan добавляет хост в known_hosts, иначе ssh спросит подтверждение и зависнет. github.ref_name для тега v1.4.0 даст v1.4.0 — на сервере выкатывается ровно эта версия.

Облачные деплои — обзорно

Деплой в облако обычно проще: провайдеры публикуют официальные экшены, которым достаточно передать секреты доступа. Например, для развёртывания статики или контейнера используют готовые экшены вендора (AWS, Azure, GCP, Vercel и т.п.) — принцип тот же: триггер по тегу/релизу → авторизация секретом → команда деплоя.

Итог

  • Деплой удобно вешать на push: tags: ["v*"] или событие release.
  • SSH-деплой: приватный ключ — в секретах, хост — в переменных, обязателен ssh-keyscan.
  • Имя версии берут из github.ref_name (тег) или github.event.release.tag_name.
Проверьте себя
1. Какой триггер запустит деплой только при пуше релизных тегов вида v1.2.3?
Aon: push с branches: [main]
Bon: push с tags: ["v*"]
Con: schedule
Don: pull_request
2. Где должен храниться приватный SSH-ключ для деплоя?
AПрямо в YAML-файле
BВ секретах (secrets), а адрес сервера можно в открытых переменных
CВ README
DВ артефакте сборки
3. Зачем в SSH-деплое выполняют ssh-keyscan хоста?
AЧтобы ускорить соединение
BЧтобы добавить хост в known_hosts и ssh не завис на запросе подтверждения ключа
CЧтобы сгенерировать новый ключ
DЧтобы зашифровать артефакт
Поддержать проект