Триггеры рабочих процессов

Триггеры рабочих процессов
Update

Триггер рабочего процесса — это событие, которые вызывает выполнение рабочего процесса раннером.

Вы можете настроить рабочие процессы так, чтобы они запускались при выполнении определенных действий на GitVerse и в запланированное время.

Некоторые события имеют несколько типов активности. Для таких событий можно указать, какие типы активности будут вызывать запуск рабочего процесса.

Триггер рабочего процессаТип активностиПримечание
createСоздание новой ветки, тега
deleteУдаление ветки, тега
forkСоздание форка репозитория
pull_requestЗапрос на слияние
assignedНазначен
closedЗакрыт
editedОтредактирован
labeledПомечен меткой
openedОткрыт
reopenedВновь открыт
synchronizeСинхронизирован
unassignedНазначение отменено
unlabeledМетка снята
pull_request_reviewРевью запроса на слияние
submittedПредставлено
editedОтредактировано
pull_request_review_commentКомментарий к ревью запроса на слияние
createdСоздан
editedОтредактирован
pull_request_targetЗапрос на слияние по конфигурации в целевой ветке
assignedНазначен
closedЗакрыт
editedОтредактирован
labeledПомечен меткой
openedОткрыт
reopenedВновь открыт
synchronizeСинхронизирован
unassignedНазначение отменено
unlabeledМетка снята
pushОтправка изменений
scheduleПланирование запусков рабочих процессов
workflow_dispatchЗапуск рабочего процесса вручную

create

Пример записи триггера события create:

name: Создание тегов
on:
  create:  # создание нового репозитория, ветки, тега
jobs:
  build-tag:
    name: Create Tag Job
    runs-on: ubuntu-cloud-runner
    steps:
      - name: Show new tag or branch details

delete

Пример записи триггера события delete в yaml-файл для облачного раннера:

name: Удаление тегов
on:
  delete:  # удаление репозитория, ветки, тега
jobs:
  cleanup-tags:
    name: Delete Tags Cleanup
    runs-on: ubuntu-latest
    steps:
      - name: Log removed tags

fork

Пример записи триггера события fork в yaml-файл для облачного раннера:

name: Fork Repository Detection
on:
  fork:  # создание форка репозитория
jobs:
  notify-fork:
    name: Notify about New Forks
    runs-on: ubuntu-latest
    steps:
      - name: Send notification on fork creation

pull_request

Пример запуска для события pull_request в .yaml-файл:

name: Демонстрация защиты ветки
on:
  pull_request:  # запрос на слияние
jobs:
  build-test:
    name: CICD branch protection
    runs-on: ubuntu-latest
    steps:
      - name: Display pull request title

Пример записи триггера события pull_request с двумя типами активности:

name: PR Assignment Tracker
on:
  pull_request:  # запрос на слияние
    types: 
      - assigned   # назначен
      - unassigned # назначение отменено
jobs:
  assignment-manager:
    name: Assign PR Reviewer
    runs-on: ubuntu-latest
    steps:
      - name: Track assignments of reviewers

Пример записи триггера события pull_request со всеми типами активности:

name: Pull Request Action Logger
on:
  pull_request:  # запрос на слияние
    # если types не указан, workflow будет срабатывать на все типы событий триггера
    types: 
      - opened        # открыт
      - closed        # закрыт
      - edited        # отредактирован
      - assigned      # назначен
      - unassigned    # назначение отменено
      - labeled       # помечен меткой
      - unlabeled     # метка снята
      - reopened      # вновь открыт
      - synchronized  # синхронизирован
jobs:
  log-pr-actions:
    name: Log All PR Activities
    runs-on: ubuntu-latest
    steps:
      - name: Track every change related to pull requests

pull_request_review

Пример записи триггера события pull_request_review со всеми типами активности:

name: Pull Request Review Logging
on:
  pull_request_review:  # ревью запроса на слияние
    # если types не указан, workflow будет срабатывать на все типы событий триггера
    types: 
      - submitted  # представлено
      - edited     # отредактировано
jobs:
  review-log:
    name: Log PR Reviews
    runs-on: ubuntu-latest
    steps:
      - name: Record every review submission or edit

Пример записи триггера события pull_request_review с двумя типами активности:

Пример записи триггера события pull_request_review_comment со всеми типами активности:

name: Pull Request Review Comment Monitoring
on:
  pull_request_review_comment:  # комментарий к ревью запроса на слияние
    # если types не указан, workflow будет срабатывать на все типы событий триггера
    types: 
      - created   # создан
      - edited    # отредактирован
jobs:
  comment-monitor:
    name: Track Review Comments
    runs-on: ubuntu-latest
    steps:
      - name: Handle review comments during PR process

pull_request_target

pull_request_review_comment

Пример записи триггера события pull_request_review_comment со всеми типами активности:

name: Target PR Assignment Tracker
on:
  pull_request_target:  # запрос на слияние по конфигурации в целевой ветке
    types: 
      - assigned   # назначен
      - unassigned # назначение отменено
jobs:
  assignment-manager:
    name: Assign PR Reviewer
    runs-on: ubuntu-latest
    steps:
      - name: Track assignments of reviewers

Пример записи триггера события pull_request_review_comment с двумя типами активности:

name: Target Pull Request Action Logger
on:
  pull_request_target:  # запрос на слияние по конфигурации в целевой ветке
    # если types не указан, workflow будет срабатывать на все типы событий триггера
    types: 
      - opened        # открыт
      - closed        # закрыт
      - edited        # отредактирован
      - assigned      # назначен
      - unassigned    # назначение отменено
      - labeled       # помечен меткой
      - unlabeled     # метка снята
      - reopened      # вновь открыт
      - synchronized  # синхронизирован
jobs:
  log-pr-actions:
    name: Log All PR Activities
    runs-on: ubuntu-latest
    steps:
      - name: Track every change related to pull requests

push

Пример записи триггера события push в yaml-файл для облачного раннера:

name: Push Monitoring
on:
  push:  # отправка изменений
jobs:
  monitor-push:
    name: Push Notification
    runs-on: ubuntu-latest
    steps:
      - name: Check pushed commits

schedule

Условия выполнения:

  1. Событие срабатывает, только если файл рабочего процесса находится в ветке по умолчанию.
  2. Запланированные процессы выполняются только в ветке по умолчанию.
  3. В публичных репозиториях такие процессы отключаются автоматически, если не было активности в течение 60 дней.
  4. Некоторые действия в репозитории могут сменить пользователя-инициатора (actor) процесса.
  5. Если у отключенного процесса пользователь с правами write изменит расписание (cron), то процесс будет повторно активирован, а этот пользователь станет новым actor.

Пример запуска по расписанию (используется cron-синтаксис стандарта POSIX):

on:
  schedule:
    - cron: "15 4,5 * * *"   # <=== Измените это значение

Cron-синтаксис использует пять полей, разделенных пробелами. Каждое поле — единица времени:

┌───────────── минута (0 - 59)
│ ┌───────────── час (0 - 23)
│ │ ┌───────────── день месяца (1 - 31)
│ │ │ ┌───────────── месяц (1 - 12 или JAN-DEC)
│ │ │ │ ┌───────────── день недели (0 - 6 или SUN-SAT)
│ │ │ │ │
* * * * *

Допустимые операторы

ОператорОписаниеПример
*любое значение15 * * * * — 15-я минута каждого часа
,список значений2,10 4,5 * * * — 2 и 10 мин. 4 и 5 часов
-диапазон значений30 4-6 * * * — 30 мин. 4–6 часов
/шаг значений20/15 * * * * — каждые 15 мин. начиная с 20-й

Поддерживается специфичный синтаксис вида: @yearly, @monthly, @weekly, @daily, @hourly.

Для генерации cron можно использовать crontab guru (opens in a new tab) или примеры cron (opens in a new tab).

workflow_dispatch
New

Событие workflow_dispatch позволяет вручную запускать рабочий процесс (workflow),что может быть очень полезно, когда требуется полный контроль над временем выполнения, а не только автоматический запуск по изменениям в коде или другим событиям.

Конфигурация workflow_dispatch

Для включения ручного запуска необходимо добавить триггер workflow_dispatch: в yaml-файл рабочего процесса в директории .gitverse/workflows/ вашего репозитория.

Пример:

name: workflow dispatch example
on:
  workflow_dispatch: # Это включает ручной запуск
jobs:
  тестовая_задача:
    runs-on: ubuntu-cloud-runner
    steps:
      - name: Приветствие
        run: echo "Привет! Я запущен вручную."

Определение входных параметров (Inputs)

Вы можете определить пользовательские входные параметры (inputs) для события workflow_dispatch. Это позволяет передавать значения в ваш рабочий процесс при его ручном запуске, и они отображаются как поля ввода. Вы можете определить неограниченное число таких параметров.

Пример с входными параметрами:

name: Пример задания входных параметров
 
on:
  workflow_dispatch:
    inputs:
      deploy_version:
        description: 'Application version to deploy'
        required: true
        default: '1.0.0'
      environment:
        description: 'Target environment (dev, staging, prod)'
        required: true
        type: choice
        options:
          - dev
          - staging
          - prod
 
jobs:
  print_inputs:
    runs-on: ubuntu-cloud-runner
    steps:
      - name: Print application version
        run: |
          echo "Application version: ${{ gitverse.event.inputs.deploy_version }}"
 
      - name: Print target environment
        run: |
          echo "Target environment: ${{ gitverse.event.inputs.environment }}"

Пользовательские входные параметры отразятся в меню запуска рабочего процесса:

Внутри рабочего процесса вы можете получить доступ к этим значениям через контекст gitverse.event.inputs, например:

${{ gitverse.event.inputs.deploy_version }}

Результат:

Запуск workflow_dispatch

    1. Перейдите на вкладку СI/CD вашего репозитория.
    2. Выберите поток.
    3. Нажмите Запустить.
    4. В открывшейся панели выберите ветку или тег.
    5. Нажмите в панели Запустить.

    Пример:

  1. Через некоторое время отобразится результат выполнения рабочего процесса. Нажмите на ссылку, чтобы перейти на страницу отчета:

  2. Проверьте результаты выполнения задач, описанных в yaml-файл:

Требование к главной ветке

yaml-файлы рабочих процессов с возможностью ручного запуска доступны только для главной ветки.

  1. Если в главной ветке нет файла рабочего процесса:

    То кнопка запуска в UI GitVerse не появится:

  2. Если главная и дополнительная ветки содержат одноименные yaml‑файлы потоков с ручной активацией, то возможность ручного запуска доступна и для дополнительной ветки с параметрами, заданными в ее файле потока в секции workflow_dispatch.

    Пример:

Перечень терминов и определений

  1. Термин хеш коммита.
  2. Термин SHA, Secure Hash Algorithm.