build(deps): django-pg-baseline 0.3.1 + własna bramka świeżości baseline - #769
Merged
Conversation
0.3.1 usunal komende `baseline_check`, ktora wola job `baseline-check` w .github/workflows/tests.yml. Dlatego #758 (dependabot) padal tam z "Unknown command: 'baseline_check'", a w #759 zaleznosc zostala celowo przypieta do <0.3.1. Ten commit zdejmuje pin. Bramka wraca do repo zamiast zniknac. Kuszaca "naprawa" — podmiana wolania na dostarczane przez pakiet `baseline_info` — dalaby zielen od reki i po cichu skasowala ochrone: `baseline_info` drukuje te same delty, ale nie zglasza bledu i ZAWSZE konczy sie zerem. Falszywa zielen jest gorsza niz czerwony job, bo nikt nie zauwazy, ze baseline.sql odjechal od migracji. Nowa komenda `src/bpp/management/commands/baseline_check.py` stoi na publicznym API pakietu (`django_pg_baseline.freshness.check_freshness`), ktore przetrwalo zmiane. Nazwa i sygnatura `--max-delta` zachowane, wiec workflow NIE wymagal zadnej zmiany (linia 191 bez zmian). Weryfikacja lokalna na 0.3.1: * `manage.py baseline_check --max-delta 50` -> "Baseline freshness OK", exit 0, na realnym repo * przekroczony prog -> CommandError, exit 1 (sprawdzone realnie, nie tylko na mockach) * 5 testow jednostkowych bramki, w tym sciezka czerwona i tresc komunikatu (ma prowadzic do `make baseline-update`, nie do golej komendy Django — patrz CLAUDE.md o fix-baseline-search-path) * komenda jest znajdowana takze przy `uv sync --frozen --no-install-project` + `uv run --no-sync`, czyli w warunkach joba CI z faktycznie ODINSTALOWANYM bpp-iplweb (manage.py wnosi src/ na sys.path) NIE zweryfikowane lokalnie: szerszy przebieg suity na 0.3.1 — host byl wysycony rownoleglymi testami z innych worktree i kontener PostgreSQL trzykrotnie nie wstal w limicie 120 s. Sam fakt, ze testy bramki przeszly przez testcontainers, dowodzi ze tworzenie testowej bazy na 0.3.1 dziala. Pelna suita: CI. Bez newsfragmentu: zmiana dotyczy narzedzi CI, bez efektu widocznego dla uzytkownika. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FPGuzMUWhUHESw6DZTtZkS
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Zdejmuje pin
<0.3.1wprowadzony w #759 i przenosi bramkę świeżości baseline'udo repo.
Tło
0.3.1 usunął komendę
baseline_check, którą woła jobbaseline-checkw
.github/workflows/tests.yml. Dlatego dependabotowe #758 padało tam zUnknown command: 'baseline_check', a w #759 zależność została celowoprzypięta do
<0.3.1.Dlaczego nie „po prostu
baseline_info"W 0.3.1 zostało
baseline_info, które drukuje te same per-app delty. Podmianawołania dałaby zieleń od ręki — i po cichu skasowała ochronę: ta komenda
nie zgłasza błędu i zawsze kończy się zerem (sprawdzone w źródle: żadnego
CommandError, żadnych argumentów).Fałszywa zieleń jest tu gorsza niż czerwony job — nikt nie zauważy, że
baseline.sqlodjechał od migracji, bo gate wygląda dokładnie tak samo jakdziałający.
Rozwiązanie
src/bpp/management/commands/baseline_check.pystoi na publicznym API pakietu(
django_pg_baseline.freshness.check_freshness), które przetrwało zmianę.Nazwa i sygnatura
--max-deltazachowane, więc workflow nie wymagał anijednej zmiany — linia 191 zostaje jak była.
Komunikat błędu prowadzi do
make baseline-update, a nie do gołegomanage.py baseline_update— zgodnie z regułą zCLAUDE.mdofix-baseline-search-path(i jest to asercją w teście).Weryfikacja lokalna na 0.3.1
baseline_check --max-delta 50na realnym repoCommandError, exit 1 — sprawdzone realnie, nie tylko na mockachuv sync --frozen --no-install-project+uv run --no-sync, z odinstalowanymbpp-iplwebmanage.pywnosisrc/nasys.path)Ostatni wiersz był realnym ryzykiem: komenda żyje w kodzie źródłowym, a job nie
instaluje pakietu projektu. Bez tego sprawdzenia merge mógłby zamienić
„naprawiony" job w czerwony na
dev.Czego NIE zweryfikowałem lokalnie
Szerszego przebiegu suity na 0.3.1 — host był wysycony równoległymi testami
z innych worktree i kontener PostgreSQL trzykrotnie nie wstał w limicie
120 s. Sam fakt, że testy bramki przeszły przez testcontainers, dowodzi że
tworzenie testowej bazy na 0.3.1 działa. Pełną suitę robi CI.
Bez newsfragmentu: zmiana dotyczy narzędzi CI, bez efektu widocznego dla
użytkownika.
🤖 Generated with Claude Code
https://claude.ai/code/session_01FPGuzMUWhUHESw6DZTtZkS