# Проверка изменений репозитория

Этот документ предназначен для работы над кодом, документацией и стендом.
Если вы выполняете учебное задание, начните с
[его самопроверки](docs/assignment/README.md#запуск-и-проверка): там объяснены
`*_dq.sql`, группы `bookings_validate` и порядок восстановления после SCD2-теста.

## Локальные проверки

Из корня репозитория:

```bash
uv sync
make lint
make test
```

`make lint` проверяет Black и isort для `airflow/` и `tests/`.
`make fmt` исправляет форматирование в этих каталогах.
Тесты находятся в трех файлах:

- [test_ods_sql_contract.py](tests/test_ods_sql_contract.py) проверяет
  контракты SQL справочников ODS по исходным файлам.
- [test_dags_smoke.py](tests/test_dags_smoke.py) проверяет структуру DAG.
  Если импорт `airflow` не предоставляет `DAG`, проверки пропускаются.
  Смотрите причины пропусков: `uv run pytest -q -rs`.
- [test_ods_snapshot_integration.py](tests/test_ods_snapshot_integration.py)
  по умолчанию пропускается; отдельный запуск описан ниже.

Успешный pytest с пропущенными smoke-тестами не подтверждает работоспособность
DAG в Airflow. Число выполненных и пропущенных тестов указывайте в отчете.

Для документации проверьте относительные ссылки и якоря, имена файлов,
таблиц и задач. Для карты выполните:

```bash
uv run docs/design/architecture-map/render.py --check
git diff --check
```

Сборщик сверяет карту с DDL, загрузками и ссылками. Действия в браузере
проверяются отдельно по [чек-листу карты](docs/design/architecture-map/README.md#проверка-в-браузере).

## Проверка на стенде

Подготовьте стенд по [README](README.md) и проверьте его состояние:

```bash
make up
docker compose ps
```

Порты берутся из `.env`: `AIRFLOW_WEB_PORT`, `GP_HOST_PORT`, `BOOKINGS_DB_PORT`.
Для локальных подключений используйте их, а для Greenplum внутри Docker-сети
применяется `GP_PORT` (по умолчанию 5432).
Загрузки используют Airflow Connections из Compose;
подробности находятся в [справочнике стенда](docs/stack.md).

Если изменились `Dockerfile.airflow` или `airflow/requirements.txt`, перед
`make up` выполните `make build`. Инициализация Bookings нужна при создании
стенда: `make bookings-init` пересоздает исходную базу из seed-дампа.
Не используйте ее для обычной проверки SQL на существующих данных.

Выполните DDL и загрузки по [порядку DAG](docs/dag_execution_order.md).
В Airflow откройте Graph и Log задач измененного слоя; в Greenplum
(`make gp-psql`) выполните проверки из его руководства:
[STG](docs/bookings_to_gp_stage.md#проверка-результата),
[ODS](docs/bookings_to_gp_ods.md#проверка-результата),
[DDS](docs/bookings_to_gp_dds.md#проверка-результата),
[DM](docs/bookings_to_gp_dm.md#проверка-результата).

Для проверки чтения через PXF используйте действующую внешнюю таблицу:

```sql
SELECT COUNT(*) FROM stg.bookings_ext;
SELECT * FROM stg.bookings_ext LIMIT 5;
```

Сравнить источник можно через `make bookings-psql`.
При ошибке соединения начните с `docker compose ps` и логов нужного сервиса,
затем проверьте настройки из `docs/stack.md`.

## Дополнительные прогоны

Интеграционный тест снимка ODS требует работающего Greenplum и базы `gp_dwh`:

```bash
RUN_ODS_INTEGRATION=1 uv run pytest -q tests/test_ods_snapshot_integration.py
```

Он создает, затем удаляет служебные таблицы
`public.it_stg_airports_ods` и `public.it_ods_airports_ods`.
Используйте тестовый стенд, где эти имена не заняты нужными данными.
Тест проверяет замену снимка, преобразование названий и DQ готового `airports`;
задания `airplanes` и `seats` он не проверяет.

`make e2e-etl` запускает DDL и два прохода STG → ODS → DDS → DM через API Airflow.
Скрипт использует `localhost:8080`; при другом `AIRFLOW_WEB_PORT` проходите
цепочку вручную. Каждый STG добавляет учебный день. Финальные SQL выводят
счетчики, но не превращают все неверные значения в ошибку завершения скрипта:
результаты нужно прочитать с учетом заглушек `main`.

`make e2e-smoke` начинает с `make clean` и **удаляет все Docker-тома стенда**,
затем инициализирует Bookings и выполняет E2E. Запускайте его только там,
где данные можно потерять. Обычный `make down` сохраняет тома;
`make stop`, затем `make up` подходят для перезапуска с сохранением данных.

[Исторический QA-план](docs/reference/qa-plan.md) сохраняет многодневные,
негативные и граничные сценарии полной реализации. Это материал для
подготовки отдельной диагностики: перед выполнением сверяйте его SQL
с текущей веткой и учитывайте операции очистки данных.

## Что указать в отчете

Укажите коммит, команды и результаты, включая пропуски тестов.
Разделите чтение исходников, проверки ссылок, действия в браузере и реальные
загрузки. Для запуска на стенде сохраните Run ID и логи проверенных задач.
Если ETL или интерфейс не проверялись, укажите это прямо.