deps: grupa python-minor-and-patch (21 pakietów, bez django-pg-baseline) - #759
Merged
Conversation
Odpowiednik dependabotowego #758, ale z JEDNYM wyjatkiem: zaleznosc django-pg-baseline zostaje na 0.3.0 zamiast isc na 0.3.1. Dlaczego wyjatek: 0.3.1 usunal komende `baseline_check`, ktora wola job `baseline-check` w .github/workflows/tests.yml (`manage.py baseline_check --max-delta 50`). Na #758 ten job padal z "Unknown command: 'baseline_check'. Did you mean baseline_update?". W 0.3.1 zostaly tylko baseline_info/baseline_load/baseline_rebuild/ baseline_update, a `baseline_info` jest czysto informacyjne — drukuje per-app deltay i ZAWSZE konczy sie zerem, wiec nie zastapi bramki. Podniesienie tej zaleznosci bez przepisania joba zamienia realny gate w dekoracje, i to akurat ten gate, ktory pilnuje czy baseline.sql nie odjechal od migracji. Migracja na 0.3.1 jest do zrobienia osobno: API django_pg_baseline.freshness.check_freshness nadal istnieje, wiec job da sie przepisac na wlasny prog. Do tego czasu pin jest jawny (>=0.3.0,<0.3.1) z uzasadnieniem w pyproject.toml, zeby kolejny dependabot nie przemycil tego po cichu. Pozostale 21 pakietow bez zmian wobec #758, m.in.: django-denorm-iplweb 1.12.2 -> 1.14.0, djangorestframework 3.17.2 -> 3.18.0, django-password-policies-iplweb 0.9.0 -> 0.9.4, django-dynamic-admin-columns 0.5.0 -> 0.6.0, django-multiseek 0.10.2 -> 0.10.3, django-channels-broadcast 0.2.2 -> 0.3.0, ruff 0.16.1 -> 0.16.2. uv.lock przelokowany uv 0.11.29 (wersja z CI). Zweryfikowane lokalnie: `manage.py baseline_check --max-delta 50` -> "Baseline freshness OK" (exit 0), `manage.py check` bez zastrzezen. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FPGuzMUWhUHESw6DZTtZkS
This was referenced Aug 13, 2026
mpasternak
added a commit
that referenced
this pull request
Aug 16, 2026
…c na baseline (#762) test_tryby_otwarte_maja_prawo_dostepu padal na CI z DoesNotExist trzy razy (dev 31638171364, PR #757, PR #759) — zawsze w shardzie 0, zawsze przy zieleni lokalnie. Za kazdym razem trzeba bylo ponawiac shard. Przyczyna: test czytal Tryb_OpenAccess_Wydawnictwo_Ciagle wprost z bazy, bez zadania jakiejkolwiek fixtury. Wiersze pochodza z migracji 0028, a coar_access_right dokłada 0480 — czyli sa w baseline i ZWYKLE sa w bazie. Transakcyjny flush (TransactionTestCase._fixture_teardown -> TRUNCATE) zmiata je, a bpp.seed_slowniki odtwarza po post_migrate WYLACZNIE RodzajJednostki. Czy test zdazy przed takim flushem, decyduje dynamiczny przydzial testow do workerow (pytest -n auto --dist load) — stad sporadycznosc przy stalej zawartosci sharda (w shardzie 0 jest 22 plikow z testami transaction=True). To ta sama klasa awarii, ktora ten plik juz raz zdiagnozowal dla charakterow i jezykow — tamte testy dostaly wtedy fixtury charaktery_formalne / jezyki, a te dwa zostaly pominiete. Naprawione OBA: test_prawa_patentowe_zmapowane mial identyczna wade i padal z tego samego powodu, tyle ze dotad nie trafil na niekorzystny podzial shardow. Fixtury nie przepisuja wartosci, tylko wolaja funkcje danych z samych migracji (0028 utworz_dane_openaccess, 0480 wypelnij), wiec nie moga rozjechac sie z produkcja — to ta sama troska, ktora pilnuja istniejace test_fixtura_json_zgodna_z_migracja / test_fixtura_jezykow_zgodna_z_migracja. Wyjatkiem sa prawa patentowe: migracja 0119 uzywa golego create(), a nazwa jest unique, wiec powtorne wywolanie oryginalu wywalilo by sie na bazie wypelnionej — stad get_or_create po tej samej liscie z bpp.initial. Reprodukcja: na bazie testowej bez danych baseline (stan rownowazny temu po TRUNCATE) z test_mapowania.py padaly DOKLADNIE te dwa testy, a pozostale 16 przechodzilo — roznica to obecnosc fixtury i nic innego. Weryfikacja: * baza pusta (reprodukujaca): 2 failed -> 18 passed; caly cerif_export 390 passed * baza z baseline (normalna, testcontainers): 390 passed — fixtury sa idempotentne, na wypelnionej bazie to no-op Bez newsfragmentu: zmiana dotyczy wylacznie testow, nie ma efektu widocznego dla uzytkownika. Claude-Session: https://claude.ai/code/session_01FPGuzMUWhUHESw6DZTtZkS Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
mpasternak
added a commit
that referenced
this pull request
Aug 16, 2026
…ine (#769) 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. Claude-Session: https://claude.ai/code/session_01FPGuzMUWhUHESw6DZTtZkS Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
Odpowiednik dependabotowego #758, z jednym wyjątkiem:
django-pg-baselinezostaje na 0.3.0 zamiast iść na 0.3.1.Dlaczego wyjątek
0.3.1 usunął komendę
baseline_check, którą woła jobbaseline-checkw
.github/workflows/tests.yml:Na #758 ten job padał z:
W 0.3.1 zostały tylko
baseline_info,baseline_load,baseline_rebuild,baseline_update.baseline_infojest czysto informacyjne — drukujeper-app delty i zawsze kończy się zerem, więc nie może pełnić roli bramki
(sprawdzone w źródle: żadnego
CommandError, żadnych argumentów).Podniesienie tej zależności bez przepisania joba zamieniłoby realny gate
w dekorację — i to akurat ten, który pilnuje, czy
baseline.sqlnie odjechałod migracji. Tuż przed wydaniem RC to zła zamiana.
Pin jest jawny (
>=0.3.0,<0.3.1) z uzasadnieniem wpyproject.toml, żebykolejny Dependabot nie przemycił tego po cichu.
Do zrobienia osobno: migracja na 0.3.1 — API
django_pg_baseline.freshness.check_freshnessnadal istnieje, więc job da sięprzepisać na własny próg.
Pozostałe 21 pakietów — bez zmian wobec #758
uv.lockprzelokowanyuv 0.11.29— wersją z CI.Weryfikacja lokalna
manage.py baseline_check --max-delta 50→ Baseline freshness OK (exit 0)manage.py check→ System check identified no issuesuv sync --all-extras --all-groups— czystopre-commit— wszystkie hooki przechodząPo zmergowaniu należy zamknąć #758 jako zastąpiony.
🤖 Generated with Claude Code
https://claude.ai/code/session_01FPGuzMUWhUHESw6DZTtZkS