CI/CD пайплайны - GitRiver Документация

Как настроить автоматическую сборку, тестирование и развёртывание в GitRiver

GitRiver имеет встроенную CI/CD-систему. Вам не нужно устанавливать внешние инструменты - всё работает из коробки.

Конфигурация описывается в YAML-файлах в директории .gitriver/workflows/, описывающие задачи (jobs) и шаги (steps).

Как это работает

Вы создаёте YAML-файл в .gitriver/workflows/ в репозитории
При push, создании пулл-реквеста или по расписанию - GitRiver проверяет все workflow-файлы
Если триггер совпадает - запускается пайплайн
Каждый job выполняется в отдельном Docker-контейнере
Результат отображается во вкладке «CI/CD» репозитория

Первый workflow

Создайте файл .gitriver/workflows/ci.yml:

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    image: node:22
    steps:
      - run: npm ci
      - run: npm test

Что здесь написано:

name - отображаемое имя пайплайна
on - когда запускать: при push в main и при создании/обновлении пулл-реквеста
jobs - набор задач. У нас одна: test
image - Docker-образ, в котором выполняются шаги
steps - последовательность команд

Отправьте файл в репозиторий (git push) - пайплайн запустится автоматически.

Триггеры - когда запускать

При push в ветку

Запускать при push в конкретные ветки:

on:
  push:
    branches: [main, develop, 'release/**']

Только при изменении определённых файлов:

on:
  push:
    branches: [main]
    paths: ['src/**', 'Cargo.toml']
    paths_ignore: ['docs/**', '*.md']

При push тега

Для сборки релизов:

on:
  push:
    tags: ['v*']

При создании/обновлении пулл-реквеста

on:
  pull_request:
    types: [opened, synchronize, reopened]
    branches: [main]

По расписанию

Для ночных сборок или периодических проверок:

on:
  schedule:
    - cron: '0 2 * * *'

Минимальный интервал - 15 минут. Выполняется на ветке по умолчанию.

Ручной запуск

Чтобы запускать пайплайн вручную из интерфейса (кнопка «Запустить»):

on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'Среда для развёртывания'
        type: choice
        options: [staging, production]

Jobs - задачи

По умолчанию задачи запускаются параллельно. Чтобы задать порядок, используйте needs:

jobs:
  build:
    image: rust:1.93
    steps:
      - run: cargo build --release

  test:
    needs: [build]
    image: rust:1.93
    steps:
      - run: cargo test

  deploy:
    needs: [test]
    if: $CI_COMMIT_BRANCH == "main"
    steps:
      - run: ./deploy.sh

Здесь test ждёт завершения build, а deploy ждёт test и запускается только для ветки main.

Docker-образ

Каждый job выполняется в Docker-контейнере. Укажите образ:

jobs:
  lint:
    image: golangci/golangci-lint:latest
    steps:
      - run: golangci-lint run

Таймаут

По умолчанию задача прерывается через 1 час. Можно изменить:

jobs:
  long-test:
    timeout: 2h
    steps:
      - run: make integration-tests

Форматы: 30s, 10m, 1h, 1h30m. Максимум - 6 часов.

Сервисные контейнеры

Если для тестов нужна база данных, Redis или другой сервис - запустите рядом:

jobs:
  test:
    image: python:3.12
    services:
      - image: postgres:16
        alias: db
        env:
          POSTGRES_DB: test
          POSTGRES_USER: test
          POSTGRES_PASSWORD: test
      - image: redis:7
        alias: cache
    env:
      DATABASE_URL: postgres://test:test@db:5432/test
      REDIS_URL: redis://cache:6379
    steps:
      - run: pip install -r requirements.txt
      - run: pytest

Сервисы доступны по алиасу (db, cache) внутри одной Docker-сети.

Артефакты

Артефакты - файлы, которые нужно сохранить после выполнения задачи (бинарники, отчёты, логи):

jobs:
  build:
    image: rust:1.93
    steps:
      - run: cargo build --release
    artifacts:
      paths:
        - target/release/myapp
      expire_in: 7 days

Артефакты доступны:

В зависимых задачах (через needs)
Для скачивания через интерфейс (вкладка «CI/CD» -> нажмите на задачу -> кнопка «Артефакты»)

Отчёты о тестах

    artifacts:
      paths:
        - target/release/myapp
      reports:
        junit: test-results.xml
        coverage_report: coverage.xml

GitRiver отобразит результаты тестов и покрытие прямо в интерфейсе.

Кеширование

Кеш ускоряет повторные сборки, сохраняя зависимости между запусками:

jobs:
  test:
    image: node:22
    cache:
      key: npm-$CI_COMMIT_BRANCH
      paths:
        - node_modules/
      policy: pull-push
    steps:
      - run: npm ci
      - run: npm test

Политика	Что делает
`pull-push`	Восстановить кеш перед задачей + сохранить после (по умолчанию)
`pull`	Только восстановить (не обновлять)
`push`	Только сохранить (полезно для задач, которые генерируют кеш)

В ключе (key) можно использовать CI-переменные: $CI_COMMIT_BRANCH, $CI_COMMIT_REF_SLUG.

Переменные окружения

В workflow-файле

Переменные можно задать на трёх уровнях:

env:
  GLOBAL_VAR: hello

jobs:
  test:
    env:
      JOB_VAR: world
    steps:
      - run: echo $GLOBAL_VAR $JOB_VAR $STEP_VAR
        env:
          STEP_VAR: "!"

В настройках репозитория

Для секретов (пароли, токены) не храните значения в YAML. Добавьте их через интерфейс:

Откройте репозиторий -> «Настройки» (шестерёнка) -> «Переменные CI/CD»
Нажмите «Добавить переменную»
Укажите имя и значение
Отметьте «Маскировать» - значение будет скрыто в логах как [MASKED]

Переменные из настроек репозитория доступны во всех задачах этого репозитория. Их можно также задать на уровне группы и инстанса (через Администрирование).

Конвейер из форка ждёт разрешения

Появилось в 1.1.0.

Открыть пулл-реквест из форка может всякий, кто пишет в свой форк, - прав на базовый репозиторий для этого не нужно. Но проверки занимают исполнители, поэтому у кода со стороны есть второй шлюз, помимо секретов.

Конвейер пулл-реквеста, автор которого не имеет права записи в базовый репозиторий, заводится, но не запускается. Он виден в списке конвейеров и на странице запроса с пометкой «ждёт разрешения»; задания стоят. Запуск разрешает любой участник с правом записи - кнопкой «Разрешить запуск» на странице конвейера или запросом:

POST /api/v1/repos/{owner}/{name}/pipelines/{id}/approve

Разрешение одноразовое и относится к одному конвейеру: следующая отправка в ветку запроса заведёт новый, и его тоже придётся разрешить. Доверие при разрешении не пересчитывается - оно взято с конвейера, поэтому секреты закрыты и после нажатия, даже если автор к тому времени получил права.

Пулл-реквест из форка, открытый участником базового репозитория, разрешения не ждёт: шлюз стоит на чужом коде, а не на форке как таковом. Секреты такому конвейеру всё равно не выдаются - код приходит из другого репозитория.

Ожидание переживает перезапуск сервера: конвейер остаётся в очереди, а не теряется.

Просмотр результатов

Откройте репозиторий в GitRiver
Перейдите во вкладку «CI/CD» (иконка ракеты)
Вы увидите список запусков пайплайнов с иконками статуса
Нажмите на запуск - откроется DAG-визуализация (какие задачи от каких зависят)
Нажмите на конкретную задачу - откроются логи в реальном времени

Кнопки:

Отменить - прервать выполнение
Перезапустить все - запустить пайплайн заново
Перезапустить упавшие - повторить только задачи с ошибкой

Бейдж статуса

Вставьте в README.md для отображения статуса CI:

![CI](https://git.example.com/owner/repo/badge.svg)

Что дальше

CI/CD - продвинутое - matrix-сборки, retry, concurrency, runner’ы, K8s
CI/CD - справочник - полный список переменных, полей, ограничений