# Эталонный фрагмент общих целей разработки для сервисов АРМ КА (arm-core, tabular-parser, scan-gateway).
# Описание целей и порядок проверок перед PR — dev/checks.md. Источник эталона: Makefile scan-gateway.
#
# Подключение (два способа, смысл одинаков):
#   1. include (в workspace и в worktree .wt/<срез>/ docs лежит рядом с сервисом):
#        include ../docs/dev/Makefile.common
#      Ставьте include ПОСЛЕ первой собственной цели сервиса или задайте `.DEFAULT_GOAL := check`,
#      иначе целью по умолчанию станет `venv` (первая цель этого файла).
#   2. копирование: скопируйте содержимое в Makefile сервиса, не меняя рецепты общих целей.
#
# Запуск — из корня репозитория сервиса; рецепты сами переходят в api/ и используют окружение api/.venv.
# Все переменные заданы через `?=`: сервис переопределяет их до include (или в командной строке: make up COMPOSE_PROJECT=x).
#
#   VENV              каталог окружения относительно корня сервиса (api/.venv)
#   BIN               каталог исполняемых файлов окружения (абсолютный путь, строится от $(CURDIR))
#   MYPY_PATHS        что проверяет mypy (src; у arm-core: src scripts)
#   COMPOSE_FILE      compose-файл инфраструктуры (../docs/dev/docker-compose.yml)
#   COMPOSE_PROJECT   имя compose-проекта; общее для всех сервисов workspace (arm-ka), поэтому целей down/stop/restart нет
#   IMAGE             тег docker-образа (по умолчанию — имя каталога сервиса)
#   CHECK_FULL_STEPS  цели `check-full` по порядку; сервис дописывает свои (arm-core: check dbml-check check-infra
#                     test-integration docker-build web-check). Собственные цели сервиса (migrate, seed, web-check ...)
#                     определяются в его Makefile, не здесь.
#
# Запускайте без `make -j`: шаги check-full вызываются последовательно через $(MAKE) и при -j, но `check: lint test` —
# пререквизиты, и при -j `lint` и `test` идут параллельно, поэтому остановка на первой упавшей проверке не гарантируется.

VENV ?= api/.venv
BIN ?= $(CURDIR)/$(VENV)/bin
MYPY_PATHS ?= src
COMPOSE_FILE ?= ../docs/dev/docker-compose.yml
COMPOSE_PROJECT ?= arm-ka
IMAGE ?= $(notdir $(CURDIR))
CHECK_FULL_STEPS ?= check test-integration docker-build

# Перевод строки для $(foreach ...) в рецепте: каждый шаг становится отдельной строкой рецепта (две пустые строки обязательны)
define newline


endef

.PHONY: venv lint test test-integration check docker-build check-full up

# Python 3.11 (версия платформы); внутренние пакеты raisa_* вне банка недоступны — пропускаем их
venv:
	cd api && uv venv --python 3.11 --allow-existing .venv
	cd api && grep -v '^raisa_' requirements.txt | uv pip install --python .venv/bin/python -r -
	cd api && grep -v '^-r' requirements-dev.txt | uv pip install --python .venv/bin/python -r -

lint:
	cd api && $(BIN)/ruff check .
	cd api && $(BIN)/ruff format --check .
	cd api && $(BIN)/mypy $(MYPY_PATHS)

test:
	cd api && $(BIN)/pytest -m "not integration"

test-integration:
	cd api && $(BIN)/pytest -m integration

check: lint test

# Образ собирается из корня репозитория; тесты в образе не запускаются
docker-build:
	docker build -t $(IMAGE) .

# Полная проверка перед PR. Шаги вызываются последовательно через $(MAKE), а не как пререквизиты:
# порядок и остановка на первой ошибке гарантированы и при make -j.
check-full:
	$(foreach step,$(CHECK_FULL_STEPS),$(MAKE) $(step)$(newline))

# Общий compose-проект workspace. --wait — только со списком долгоживущих сервисов: одноразовый minio-init
# завершается кодом 0, и compose считает это сбоем. Бакет arm-ka создаётся отдельным идемпотентным шагом.
up:
	docker compose -f $(COMPOSE_FILE) --project-name $(COMPOSE_PROJECT) up -d --wait postgres nats minio
	docker compose -f $(COMPOSE_FILE) --project-name $(COMPOSE_PROJECT) run --rm minio-init