#2745 - ci: пропуск теста обязан назвать себя — иначе прогон красный - lekss361/gendesign

bot-backend commented

2026-08-06 17:10:38 +00:00

Collaborator

Summary

Вторая половина ревизии пропусков (первая — #2744, только тесты). Здесь — пайплайн.

Общее у #2722, #2729 и #2740 — не три бага, а один: пропуск, которого не видно. Под pytest -q пропуск рисуется точкой s, неотличимой от прогона.

1. -rs во всех pytest-шагах (ci.yml, ci-tradein.yml backend + browser) — каждый пропуск печатает причину в лог job'а.

2. Postgres-сервисы вместо заглушечных DSN.

ci-tradein: DATABASE_URL вёл на заведомо мёртвый localhost:5432/test → 9 тестов с _live_session() в CI не бежали ни разу. Именно так #2740 разъехался со схемой. Теперь postgis-сервис + сборка схемы из backend/data/sql/ тем же строгим циклом, что в deploy-tradein.yml. Единственное исключение названо вслух в коде: 077 (backfill через postgres_fdw к БД другого стека).
ci.yml: plain postgres:16 поднимает 10 тестов SQL-логики (#17, #99, #295), не бежавших с момента написания. TEST_DATABASE_URL намеренно НЕ задан — на нём висит phantom-column gate, которому нужна копия ПРОДОВОЙ схемы.

Замер до включения (живая БД не медленнее, поэтому не второй job, а починка существующего):

лэйн	было (mock)	стало (живая БД)
tradein	122с · 3858 passed · 10 skipped	106с · 3867 passed · 1 skipped
backend	783с · 4594 passed · 48 skipped	723с · 4604 passed · 38 skipped

3. skip_allowlist.txt + хук в conftest обоих сьютов. Пропущено может быть только объявленное с причиной; любой новый пропуск роняет прогон. Список — заодно инвентарь: против каждой записи сказано, почему проверку нельзя выполнить здесь и где она выполняется вместо этого. xfail тоже попадает под учёт (pytest рапортует его как skipped).

Test plan

backend в конфигурации этого PR: 4604 passed / 38 skipped / exit 0
tradein: 3858 passed / 10 skipped / exit 0; при удалённом allowlist тот же прогон → exit 1 + печать неучтённых
YAML обоих workflow парсится, ruff + ruff format чистые
после мержа: проверить в логе прогона, что postgres-сервис поднялся, схема собралась и число пропусков совпало с ожидаемым

Refs #2722 #2729 #2740

## Summary Вторая половина ревизии пропусков (первая — #2744, только тесты). Здесь — пайплайн. Общее у #2722, #2729 и #2740 — не три бага, а один: **пропуск, которого не видно**. Под `pytest -q` пропуск рисуется точкой `s`, неотличимой от прогона. **1. `-rs` во всех pytest-шагах** (ci.yml, ci-tradein.yml backend + browser) — каждый пропуск печатает причину в лог job'а. **2. Postgres-сервисы вместо заглушечных DSN.** - `ci-tradein`: DATABASE_URL вёл на заведомо мёртвый `localhost:5432/test` → **9 тестов с `_live_session()` в CI не бежали ни разу**. Именно так #2740 разъехался со схемой. Теперь postgis-сервис + сборка схемы из `backend/data/sql/` тем же строгим циклом, что в `deploy-tradein.yml`. Единственное исключение названо вслух в коде: `077` (backfill через postgres_fdw к БД другого стека). - `ci.yml`: plain `postgres:16` поднимает **10 тестов SQL-логики** (#17, #99, #295), не бежавших с момента написания. `TEST_DATABASE_URL` намеренно НЕ задан — на нём висит phantom-column gate, которому нужна копия ПРОДОВОЙ схемы. **Замер до включения** (живая БД не медленнее, поэтому не второй job, а починка существующего): | лэйн | было (mock) | стало (живая БД) | |---|---|---| | tradein | 122с · 3858 passed · 10 skipped | 106с · 3867 passed · 1 skipped | | backend | 783с · 4594 passed · 48 skipped | 723с · 4604 passed · 38 skipped | **3. `skip_allowlist.txt` + хук в conftest обоих сьютов.** Пропущено может быть только объявленное с причиной; любой новый пропуск роняет прогон. Список — заодно инвентарь: против каждой записи сказано, почему проверку нельзя выполнить здесь и где она выполняется вместо этого. xfail тоже попадает под учёт (pytest рапортует его как skipped). ## Test plan - [x] backend в конфигурации этого PR: **4604 passed / 38 skipped / exit 0** - [x] tradein: **3858 passed / 10 skipped / exit 0**; при удалённом allowlist тот же прогон → **exit 1** + печать неучтённых - [x] YAML обоих workflow парсится, `ruff` + `ruff format` чистые - [ ] после мержа: проверить в логе прогона, что postgres-сервис поднялся, схема собралась и число пропусков совпало с ожидаемым Refs #2722 #2729 #2740

bot-backend added 1 commit 2026-08-06 17:10:38 +00:00

ci: пропуск теста обязан назвать себя — иначе прогон красный

CI Trade-In / changes (pull_request) Successful in 8s

Details

CI / changes (pull_request) Successful in 8s

Details

CI Trade-In / backend-tests (pull_request) Failing after 21s

Details

CI Trade-In / browser-tests (pull_request) Successful in 51s

Details

CI Trade-In / frontend-checks (pull_request) Successful in 1m31s

Details

CI / frontend-tests (pull_request) Successful in 1m20s

Details

CI / openapi-codegen-check (pull_request) Successful in 2m3s

Details

CI / backend-tests (pull_request) Successful in 15m46s

Details

1fa3cb6949

Общее у #2722, #2729 и #2740 — не три разных бага, а один: пропуск, которого
не видно. Под `pytest -q` пропуск рисуется точкой `s`, неотличимой от прогона,
и проверка годами «зелёная», ничего не проверяя. Три меры, от дешёвой к
жёсткой.

1. `-rs` во всех pytest-шагах (ci.yml, ci-tradein.yml backend+browser).
Каждый пропуск печатает причину в лог job'а. Одна опция — и молчаливых
пропусков больше нет ни одного.

2. Postgres-сервисы вместо заглушечных DSN.
ci-tradein: DATABASE_URL вёл на заведомо мёртвый localhost:5432/test, и
девять тестов с `_live_session()` self-skip'ались — в CI не бежали НИ РАЗУ.
Именно так #2740 разъехался со схемой (houses.url стал NOT NULL), а
test_gar_flats_loader падал до первого утверждения (#2744). Теперь
postgis-сервис + сборка схемы из backend/data/sql/ тем же строгим циклом,
что в deploy-tradein.yml (ON_ERROR_STOP, падение миграции → job RED).
Единственное исключение названо вслух в коде: 077 — backfill через
postgres_fdw к БД другого стека, которой в CI нет.
ci.yml: plain postgres:16 (без PostGIS — tests/sql/ строят себе временные
таблицы) поднимает 10 тестов SQL-логики (#17, #99, #295), не бежавших с
момента написания. TEST_DATABASE_URL намеренно НЕ задан: на нём висит
phantom-column gate, которому нужна копия ПРОДОВОЙ схемы, и пустой
контейнер дал бы там красноту на пустом месте.

Замер до включения: tradein 122с/3858 passed/10 skipped на моке против
106с/3867 passed/1 skipped на живой БД; backend 783с/4594/48 против
723с/4604/38. Живая БД не медленнее — поэтому не второй job, а починка
существующего. Накладные: подъём сервиса + bootstrap схемы (219 файлов,
~20с в tradein; в backend схема не нужна вовсе).

3. skip_allowlist.txt + хук в conftest обоих сьютов.
Пропущено может быть только то, что объявлено с причиной. Любой новый
пропуск — дописал кто-то skipif «пока починю», отвалилась зависимость,
исчезла БД — роняет прогон. Список это ещё и инвентарь: против каждой
записи сказано, почему проверку нельзя выполнить здесь и где она
выполняется вместо этого. Сюда же попадает xfail (pytest рапортует его
как skipped), так что xfail без strict=True тоже придётся объявить.
Список — надмножество сред: в CI часть записей не срабатывает, на ноутбуке
без Postgres и native-libs — срабатывает; лишняя запись безвредна,
пропуск без записи — нет.

Проверено локально в конфигурации, которую задаёт этот PR: backend
4604 passed / 38 skipped / exit 0, tradein 3858 passed / 10 skipped / exit 0;
при удалённом allowlist тот же прогон даёт exit 1 и печатает неучтённые.

Light1YT referenced this pull request from a commit

2026-08-06 17:23:55 +00:00

fix(ci): тестовый Postgres — свой контейнер, а не `services:` на порту прода

Light1YT added 1 commit 2026-08-06 17:23:56 +00:00

fix(ci): тестовый Postgres — свой контейнер, а не services: на порту прода

CI / changes (pull_request) Successful in 9s

Details

CI Trade-In / changes (pull_request) Successful in 9s

Details

CI Trade-In / backend-tests (pull_request) Failing after 20s

Details

CI Trade-In / browser-tests (pull_request) Successful in 57s

Details

CI / frontend-tests (pull_request) Successful in 1m39s

Details

CI Trade-In / frontend-checks (pull_request) Successful in 1m37s

Details

CI / openapi-codegen-check (pull_request) Successful in 2m37s

Details

CI / backend-tests (pull_request) Successful in 16m7s

Details

a07da68a37

Первая версия (#2745, прогон 6853) упала, и упала полезно: `services:` +
`ports: 5432:5432` на этом раннере означает не то, что кажется. Раннер
запускает и job, и сервис-контейнеры с `--network host` (в логе:
`docker create image=... network="host"`), а на 5432 того же хоста слушает
ПРОДОВЫЙ Postgres. Сервис-контейнер порт занять не смог, а psql из job'а ушёл
в прод и получил `password authentication failed for user "tradein"`.

То есть `localhost:5432` из CI-job'а на vps-runner — это боевая база. Тест,
чьи креды случайно подошли бы, писал бы в прод. Поэтому здесь нельзя
публиковать порты вообще.

Теперь контейнер поднимается явным `docker run` в дефолтной bridge-сети, БЕЗ
`-p`, а DSN собирается из его собственного IP и уезжает в $GITHUB_ENV. Плюсы
помимо безопасности: имя контейнера содержит github.run_id (параллельные PR не
дерутся), psql берётся из самого контейнера (ушёл apt-get postgresql-client),
снос контейнера в шаге с if: always().

Light1YT added 1 commit 2026-08-06 17:36:21 +00:00

fix(ci): ждать настоящий Postgres, а не временный сервер фазы initdb

CI / changes (pull_request) Successful in 9s

Details

CI Trade-In / changes (pull_request) Successful in 9s

Details

CI Trade-In / browser-tests (pull_request) Successful in 52s

Details

CI Trade-In / frontend-checks (pull_request) Successful in 1m38s

Details

CI / frontend-tests (pull_request) Successful in 1m44s

Details

CI / openapi-codegen-check (pull_request) Successful in 2m20s

Details

CI Trade-In / backend-tests (pull_request) Successful in 4m31s

Details

CI / backend-tests (pull_request) Successful in 15m35s

Details

cfde033c2f

Прогон 6859: контейнер поднялся, `pg_isready` сказал «accepting connections»,
через 1.4с bootstrap упал на `container is not running`. Причина — проба шла
через unix-сокет, а по сокету отвечает ВРЕМЕННЫЙ сервер, который образ
postgres поднимает на время initdb с listen_addresses=''. Снаружи БД в этот
момент ещё не существует, и впереди рестарт: мы поймали окно и приняли его за
готовность. Классическая ложная зелень — проверка сказала «готово» про не то.

Теперь проба `pg_isready -h 127.0.0.1` (TCP) — зеленеет только на настоящем
сервере, том самом, к которому пойдут тесты. Плюс: цикл ждёт до 90с и
прерывается, если контейнер вышел; при неудаче печатается статус, код выхода
и `docker logs`. Подъём и bootstrap слиты в ОДИН шаг — между шагами контейнер
успевал исчезнуть.