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

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

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

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

⚠️

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

В разделе Настройка CI/CD подробно рассмотрены примеры с:

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

Составной рабочий процесс в 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

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

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: синхронизация запроса.

Пример записи события pull_request в CICD_branch_protection_demo.yaml:

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

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

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

организация;
облачный;
локальный.

Пример:

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

Для того чтобы ограничить потребление ресурсов для контейнера с выполняемой задачей, необходимо добавить блок 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 является обязательным параметром.