ci — общие CI-пайплайны

Публичный репозиторий sikorskiy/ci в Forgejo. Проекты подключают отсюда общий workflow, чтобы не копировать CI в каждый репозиторий.

Репозиторий должен быть публичным: Forgejo загружает reusable workflows только из публичных репозиториев. Секретов здесь нет — они берутся из настроек вызывающего репозитория (secrets: inherit).

Подключить проект

1. Скопировать examples/ci.yaml в проект как .forgejo/workflows/ci.yaml.
2. В Forgejo (один раз в настройках пользователя: Settings → Actions):
   • Secrets: REGISTRY_USER, REGISTRY_TOKEN (права package: read+write);
   • Variables: REGISTRY = git.zimmablue.ru.
3. Защитить main (Settings → Branches): Disable push, Require status checks → ci / docker (push) (появится в списке после первого прогона).

Что происходит

Событие	Проверки	Публикация
push в любую ветку	hadolint, trivy (секреты, конфиг, образ), SBOM	нет
Run workflow (Actions) на main	то же	как при merge — пересборка без нового коммита
push в main (merge PR)	то же	образ vN.0.0 + latest, SBOM, git-тег vN.0.0

Версия: следующая мажорная по git-тегам проекта (v3.0.0 → v4.0.0, без тегов — v1.0.0).

Параметры with:

Параметр	По умолчанию
release-branch	main	push в эту ветку (или ручной запуск на ней) публикует версию
context	.	контекст сборки
dockerfile	Dockerfile	путь к Dockerfile
trivy-severity	HIGH,CRITICAL	какие уязвимости валят сборку
env-file	.env	env-файл проекта со ссылками на переменные/секреты Forgejo

Изменения пайплайна

Проекты ссылаются на @main — правка здесь сразу применяется ко всем проектам. Проверять изменения в ветке: в проекте временно указать @<ветка> вместо @main.

Переменные окружения (.env в репозитории проекта)

.env коммитится в git: в нём нет значений секретов — только обычные значения и ссылки на переменные/секреты Forgejo (Settings → Actions → Variables / Secrets репозитория, пользователя или организации):

TARGET_VERSION=latest
HTTP_PORT=80
SITE_NAME=forgejo:vars.SITE_NAME
INFO_TOKEN=forgejo:secrets.INFO_TOKEN

Синтаксис forgejo:... выбран потому, что docker compose читает его как обычный текст (с ${{ ... }} compose падает с Invalid template).

Если .env есть, CI на каждом прогоне:

1. подставляет значения по ссылкам (имена без учёта регистра, пустое = не задано); если чего-то нет — сборка падает со списком недостающих имён;
2. запускает собранный образ с этими значениями и ждёт healthy (smoke test).

Готовый файл со значениями остаётся только внутри задания и никуда не выгружается. В .env указывать только то, что нужно параметризовать. В compose весь файл уходит в контейнер через env_file, перечислять переменные не нужно:

services:
  app:
    env_file:
      - path: .env
      - path: .env.local      # локальные значения, в .gitignore
        required: false

Локальный запуск: настоящие значения в .env.local, затем docker compose up --build. Подстановки в самом compose.yaml (${TARGET_VERSION}, ${HTTP_PORT}) берутся только из .env; другой порт локально: HTTP_PORT=8080 docker compose up. Обязательные для compose значения задавать без умолчаний: ${HTTP_PORT:?set HTTP_PORT in .env}.