CI/CD Integration¶

Hive интегрируется с GitLab CI через динамическую генерацию pipeline.

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

graph LR
    A[git push] --> B[generate-pipeline]
    B -->|hive ci --global| C[child-pipeline.yml]
    C --> D[run-pipeline]
    D --> E[init]
    E --> F[build]
    F --> G[test]
    G --> H[deploy]

git push запускает основной pipeline
Stage generate вызывает hive ci --global — генерирует CI jobs из .hive.yml файлов
Stage run запускает сгенерированный pipeline как child pipeline
Child pipeline: init → build → test → deploy для каждого сервиса

Настройка¶

`.gitlab-ci.yml` (корень репозитория)¶

stages:
  - generate
  - run

generate-pipeline:
  stage: generate
  image: lab.xmonetize.net:5050/infrastructure/hive/hive-api/cli:latest
  script:
    - hive ci --global > child-pipeline.yml
  artifacts:
    paths:
      - child-pipeline.yml

run-pipeline:
  stage: run
  trigger:
    include:
      - artifact: child-pipeline.yml
        job: generate-pipeline
    strategy: depend

Это всё. Один раз настроили — дальше pipeline обновляется автоматически при добавлении/удалении сервисов.

Что генерируется¶

init¶

Регистрирует репозиторий в ArgoCD (создаёт deploy token, добавляет репо). Один job на весь pipeline, не per-service.

Image: lab.xmonetize.net:5050/infrastructure/hive/hive-api/cli:latest
Идемпотентный: если репо уже зарегистрирован — просто пропускает
Запуск: только на default branch

Для каждого сервиса создаются три jobs:

build-{name}¶

Собирает контейнер через Cloud Native Buildpacks.

Image: lab.xmonetize.net:5050/infrastructure/hive/hive-api/cli:latest
Services: docker:27-dind (Docker-in-Docker)
Запуск: только на default branch

test-{name}¶

Запускает контейнер и проверяет health endpoint.

Depends on: build-{name}
Services: docker:27-dind
Artifacts: JUnit XML отчёт (hive-test-report.xml)

deploy-{name}¶

Деплоит через Hive API → ArgoCD → Knative.

Depends on: test-{name}
Запуск: только на default branch

Переменные CI¶

Эти переменные должны быть настроены в GitLab CI/CD Settings:

Переменная	Описание	Где настроить
`HIVE_API_URL`	URL Hive API	CI/CD Variables (группа или проект)
`HIVE_API_TOKEN`	Bearer token	CI/CD Variables (masked)
`ARGOCD_URL`	URL ArgoCD (для bootstrap)	CI/CD Variables, scoped по environment
`ARGOCD_TOKEN`	Токен ArgoCD (для bootstrap)	CI/CD Variables, scoped по environment
`CI_REGISTRY_IMAGE`	Авто — адрес в registry	Автоматически GitLab
`CI_COMMIT_SHORT_SHA`	Авто — SHA коммита	Автоматически GitLab

Секреты

HIVE_API_TOKEN должен быть masked и protected. Никогда не коммитьте токены в репозиторий.

Multi-service pipeline¶

Для multi-service репозитория генерируются параллельные цепочки:

         ┌→ build-frontend  → test-frontend  → deploy-frontend
init ────┼→ build-backend   → test-backend   → deploy-backend
         └→ build-worker    → test-worker    → deploy-worker

Каждый сервис собирается и деплоится независимо. CI_REGISTRY_IMAGE дополняется суффиксом /{name}.

Сервисы с type: cronjobs пропускают stage test (нет HTTP порта для probe):

         ┌→ build-api        → test-api        → deploy-api
init ────┼→ build-frontend   → test-frontend   → deploy-frontend
         └→ build-workers    ──────────────────→ deploy-workers  (cronjobs)

JUnit отчёты¶

Stage test генерирует JUnit XML. GitLab автоматически показывает результаты тестов в Merge Request:

artifacts:
  when: always
  reports:
    junit: hive-test-report.xml

Если тест провалился, в отчёте будут логи контейнера — это помогает быстро найти причину.

Фильтрация по веткам¶

Фильтрация веток управляется в родительском .gitlab-ci.yml через rules:, а не в сгенерированном child pipeline. Это позволяет контролировать, какие ветки запускают сборку и деплой, в одном месте:

# .gitlab-ci.yml (родительский pipeline)
generate-pipeline-staging:
  # ...
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

run-pipeline-staging:
  # ...
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Чтобы включить деплой из feature branches, измените rules: в вашем .gitlab-ci.yml.

Окружения¶

Hive поддерживает несколько окружений. Переменные для каждого окружения (HIVE_API_URL, HIVE_DOMAIN) определяются в cli/environments.yaml — единственном источнике истины. Когда hive ci --global -E <name> генерирует pipeline, эти переменные инжектятся напрямую в сгенерированный YAML.

Это решает проблему того, что GitLab environment-scoped variables не пробрасываются в child pipelines.

Окружение	Домен	Hive API
staging	`knative-staging.svcik.org`	`api.hive-api.knative-staging.svcik.org`
production	`knative.svcik.org`	`api.hive-api.knative.svcik.org`

`cli/environments.yaml`¶

environments:
  staging:
    HIVE_API_URL: "https://api.hive-api.knative-staging.svcik.org"
    HIVE_DOMAIN: "knative-staging.svcik.org"

  production:
    HIVE_API_URL: "https://api.hive-api.knative.svcik.org"
    HIVE_DOMAIN: "knative.svcik.org"

Чтобы добавить новое окружение, добавьте запись в этот файл. Переменные инжектятся в init и deploy jobs сгенерированного pipeline.

Multi-environment `.gitlab-ci.yml`¶

stages:
  - generate
  - staging
  - production

generate-pipeline-staging:
  stage: generate
  image: lab.xmonetize.net:5050/infrastructure/hive/hive-api/cli:latest
  script:
    - hive ci --global -E staging > child-pipeline-staging.yml
  artifacts:
    paths:
      - child-pipeline-staging.yml
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

run-pipeline-staging:
  stage: staging
  trigger:
    include:
      - artifact: child-pipeline-staging.yml
        job: generate-pipeline-staging
    strategy: depend
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

# Production — раскомментируйте когда будет готово
# generate-pipeline-production:
#   stage: generate
#   ...
#   script:
#     - hive ci --global -E production > child-pipeline-production.yml