Рабочие процессы

Файл рабочего процесса (workflow) - это файл .yaml, определяющий конфигурацию, последовательность заданий (jobs) и шагов (steps), которые должны быть выполнены в рамках GitVerse CI/CD.

.yaml-файлы рабочих процессов выполняются раннерами GitVerse CI/CD.

Конфигурационные файлы рабочих процессов GitVerse Actions должны быть написаны в синтаксисе YAML и располагаться в .gitverse/workflows/ вашего репозитория:

сохраните файл с расширением .yaml;
поместите его в .gitverse/workflows/ в вашем репозитории (например, .gitverse/workflows/demo.yaml).

⚠️

Раннер так же обработает .yaml файлы в директории .github/workflows.

Типы раннеров

Кроме уровней в GitVerse раннеры различаются по типам:

Пример:

Поддерживаемые события
Update

create: создание нового репозитория, ветки, тега.
delete: удаление репозитория, ветки, тега.
fork: создание форка репозитория.
push: пуш в репозиторий.
pull_request: создание или обновление запроса.
pull_request_assign: назначение запроса.
pull_request_comment: комментарий к запросу.
pull_request_review_approved: утверждение рецензии запроса.
pull_request_review_rejected: отклонение рецензии запроса.
pull_request_review_comment: комментарий к рецензии запроса.
pull_request_sync: синхронизация запроса.
schedule: запуск по расписанию.

`pull_request`

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

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

`schedule`
New

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

Событие срабатывает, только если файл рабочего процесса находится в ветке по умолчанию.
Запланированные процессы выполняются только в ветке по умолчанию.
В публичных репозиториях такие процессы отключаются автоматически, если не было активности в течение 60 дней.
Некоторые действия в репозитории могут сменить пользователя-инициатора (actor) процесса.
Если у отключённого процесса пользователь с правами 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).

Составной рабочий процесс

Составной рабочий процесс в GitVerse CI/CD — это механизм, позволяющий подключать в целевой рабочий процесс .yaml-файлы, хранящиеся в других репозиториях.

Основные характеристики составного рабочего процесса:

Переиспользование. Позволяет переиспользовать код, тем самым избавляясь от лишнего дублирования.
Модульность. Разбивает сложные рабочие процессы на более мелкие, управляемые части.
Централизованное управление. Изменения автоматически применяются ко всем рабочим процессам, которые его используют.

Требования к подключаемому .yaml-файлу:

Должен находиться в корне репозитория и называться action.yaml.
Для коммита ним требуется создать тег.
Должен в своем составе конструкцию using: "composite".

Требования к проекту с целевым yaml-файлом, он должен:

Находиться в директории .gitverse/workflows/ вашего проекта;
Содержать конструкции uses: <username пользователя GitVerse>/<название репозитория>@<тег коммита>.

Подробнее см. раздел Составной рабочий процесс, пример.

Матричная конфигурация и выполнение

Матрица — способ запуска нескольких задач параллельно с различными комбинациями параметров.

Для задания матрицы в GitVerse, вы должны использовать ключевое слово matrix внутри блока strategy и runs-on: ${{ matrix.os }}. Внутри matrix вы можете указать параметры, которые будут использоваться для создания различных комбинаций.

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

Пример:

jobs:
  build:
    strategy:
      matrix:
        node-version: [12, 14, 16] # Разные версии Node.js
        os: [ubuntu-latest, windows-latest] # Разные операционные системы
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v2
      - name: Set up Node.js
        uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm install
      - run: npm test

Пользовательский таймаут выполнения
New

jobs.<job_id>.steps[*].timeout-minutes — максимальная продолжительность выполнения шага (в минутах), по истечении которой процесс будет остановлен.

Значение параметра timeout-minutes должно быть целым положительным числом, дробные значения недопустимы.
jobs.<job_id>.timeout-minutes — максимальное время выполнения задачи (в минутах), после которого GitVerse автоматически его отменит.

Значение таймаут по умолчанию:

15 минут для облачного раннера;
3 часа для локального раннера.

Если время выполнения задания превышает установленный для раннера лимит, задание будет отменено.

Запуск локального раннера с ограничениями на ресурсы

Для того чтобы ограничить потребление ресурсов для контейнера с выполняемой задачей, необходимо добавить блок container.options с обязательным параметром --net=bridge. В блоке можно прописать любые опции, с которыми запускается обычный контейнер, например:

    container:
      options: --cpus=0.5 --memory=2G --net=bridge ## Ограничения по CPU (50%) и RAM, --net=bridge - обязательный параметр

В данном примере на контейнер с задачей наложены дополнительные ограничения: --cpus=0.5 ограничивает на 50 % использование CPU, --memory=2G накладывает ограничение на RAM, --net=bridge является обязательным параметром.

Страница отчета выполнения CI/CD

Для просмотра или скачивания логов выполнения рабочего процесса, для проверки статуса заданий перейдите в профиле репозитория и далее:

Выберите вкладку CI/CD.
Перейдите на страницу отчета.

Пример:

Просмотр логов выполнения
New

Для просмотра логов в исходном формате нажмите на пиктограмму в правой части страницы:

Отобразится страница с отчетом в исходном формате:

Скачивание логов выполнения
New

После завершения работы раннера становятся доступны для скачивания логи выполнения задач рабочего процесса. Для скачивания логов нажмите на пиктограмму скачивания в правой части страницы: