Сценарий непрерывной интеграции (`ci`)¶

Переменная ODPM_SCENARIO=ci — подготовка готового Docker-образа проекта: исходники платформы, дополнения, окружение Python и конфигурация встроены в образ, каталоги Odoo не подключаются с диска машины сборки.

Назначение¶

Инженер сборки или конвейер автоматизации получает воспроизводимый артефакт: один и тот же код и те же зафиксированные ревизии git, что описаны в odpm.json и .odpm/deps.lock.json. После сборки образ можно публиковать в реестр и разворачивать на стендах теми средствами, которые уже приняты в организации.

odpm не заменяет GitHub Actions, GitLab CI или оркестраторы — он даёт команду сборки образа и согласованный способ запуска Odoo с теми же параметрами, что у разработчика и администратора.

Поведение окружения¶

Область	Как устроено
Образ	Создаётся командой `odpm build` (доступна только в этом сценарии). Бэкенд: `docker` (по умолчанию) или `kaniko` — см. ADR-016.
Исходники	Внутри образа, без подключения с хоста.
Окружение Python	Собрано при сборке образа, не пересоздаётся при каждом `up`.
Отладчик	Нет.
Секреты модулей	Mount `.odpm/secrets.json` с хоста отключён. Секреты приложения в CI-образ этим механизмом не попадают — см. локальные секреты (TD-FEAT-09).
Фиксация версий	Строгая проверка `.odpm/deps.lock.json`; несовместимости версий во вложенных описаниях — ошибка.
Base image	По умолчанию профиль ci (slim Dockerfile): без Chromium/Xvfb/IDE; отдельный тег `odoo-…-ci`; пересборка при смене шаблона или `Dockerfile` — см. ADR-007. Override: `ODPM_BASE_IMAGE_PROFILE` = `full` / `medium` / `ci`. Для `kaniko` base собирается и пушится в `ODPM_BASE_IMAGE_REGISTRY` (ADR-019); final `FROM` использует registry ref. Existence для kaniko — local identity stamp (не probe registry); при stale registry удалите `.odpm/base_image_identity.json` и пересоберите.

Типичный конвейер¶

отправка в git → машина сборки
  → ODPM_SCENARIO=ci
  → odpm prepare
  → odpm build [--image-tag реестр/проект:метка] [--image-builder docker|kaniko] [--image-push]
  → публикация образа (или --image-push / артефакт tar для kaniko)
  → развёртывание (ваши инструменты)

Чеклист¶

В git: odpm.json и закоммиченный .odpm/deps.lock.json.
На машине сборки: odpm, .env с ODPM_SCENARIO=ci; для docker — Docker daemon; для kaniko — executor (docker-run или direct) и pullable base из registry.
Перед слиянием: odpm plan --strict — код возврата 1 при неожиданных изменениях.
Проверка: HTTP-ответ 200 на /web после docker compose up.

Примеры команд¶

# ~/.odpm/.env (daemonless)
# ODPM_SCENARIO=ci
# ODOO_PROJECTS_DIR=/data/odoo_projects
# ODPM_CI_IMAGE_BUILDER=kaniko
# ODPM_KANIKO_EXECUTOR_MODE=direct
# ODPM_BASE_IMAGE_REGISTRY=registry.example.com/odpm
# ODPM_CI_IMAGE_PUSH=1

export ODPM_SCENARIO=ci
odpm prepare
odpm build --image-tag myregistry/client-odoo:19.0
odpm build --image-builder kaniko --image-tag myregistry/client-odoo:19.0 --image-push
ODPM_CI_IMAGE_BUILDER=kaniko ODPM_KANIKO_EXECUTOR_MODE=direct \
  ODPM_BASE_IMAGE_REGISTRY=registry.example.com/odpm \
  odpm build --image-tag myregistry/client-odoo:19.0 --image-push
docker compose up -d
# Module install after stack is up (bare `odpm up -d/-i` / legacy root flags is rejected in ci).
# Physical odoo key from docker-compose.yml (odoo / acme-odoo / odoo-dev / …):
ODOO_SVC=odoo
docker compose exec "$ODOO_SVC" odoo-bin -d test_db -i base --stop-after-init

В сценарии ci запрещены odpm up, scaffold и стековые database backup|restore|drop|list. Разрешены prepare / build / init / plan / manifest / modules / run / host-database / --version/-V (и legacy-синонимы) — см. ADR-017, ADR-026.

Внешняя PostgreSQL в `ci` (ADR-022)¶

В effective slice ci можно задать db_* в odoo_conf.options (в developer / server эти ключи по-прежнему запрещены). Credentials лучше через ${@secret:…}:

"scenarios": {
  "ci": {
    "odoo_conf": {
      "options": {
        "db_host": "10.241.2.102",
        "db_port": 5000,
        "db_user": "${@secret:pg_user}",
        "db_password": "${@secret:pg_user_password}",
        "proxy_mode": "True",
        "server_wide_modules": "base,web,queue_job"
      }
    }
  }
}

Значения попадают в odoo_config_data через обычный merge (disk → manifest). Compose-сервис db не удаляется; host-side odpm database / ensure_app_role остаются привязаны к compose postgres. См. odoo.conf, ADR-022.

Без --image-push бэкенд kaniko пишет tar в .odpm/ci-build-context/odpm-ci-image.tar.

В режиме docker-run с --image-push нужен ~/.docker/config.json (docker login); иначе odpm завершится с ошибкой до запуска executor. Образ executor по умолчанию закреплён (gcr.io/kaniko-project/executor:v1.23.2); перекрывается ODPM_KANIKO_EXECUTOR_IMAGE. Opt-in Docker integration в CI покрывает только бэкенд docker; argv/direct для kaniko — unit-тесты.

Для direct под non-root пользователем сборки: odpm не работает от root, но Kaniko executor часто требует привилегий. Задайте ODPM_KANIKO_EXECUTOR_WRAPPER — скрипт, запускающий executor от root (рекомендуется), или ODPM_KANIKO_EXECUTOR_SUDO=1 с passwordless sudo для бинаря executor. Опционально ODPM_KANIKO_EXECUTOR_EXTRA_FLAGS (напр. --kaniko-dir=/tmp/kaniko) для путей runtime Kaniko. См. ADR-016.

Инициализация без диалогов:

export ODPM_SCENARIO=ci
export ODOO_PROJECTS_DIR=/data/odoo_projects
export BACKUP_DIR=/data/backups
# init без compose up (4.8: legacy-комбо; иначе odpm init поднимает стек)
odpm --init https://github.com/example/demo.git --skip-start

См. запуск без диалогов.

Сценарий непрерывной интеграции (ci)¶