GitRiver GitRiver
EN
Навигация

CI/CD пайплайны

Как настроить автоматическую сборку, тестирование и деплой в GitRiver

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

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

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

  1. Вы создаёте YAML-файл в .gitriver/workflows/ в репозитории
  2. При push, создании пулл-реквеста или по расписанию - GitRiver проверяет все workflow-файлы
  3. Если триггер совпадает - запускается пайплайн
  4. Каждый job выполняется в отдельном Docker-контейнере
  5. Результат отображается во вкладке «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. Добавьте их через интерфейс:

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

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

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

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

Кнопки:

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

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

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

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

Что дальше