gitea
0a1a0a3499
Testy / Testy warstwy logicznej (silnik) (pull_request) Successful in 10m31s
Testy / Testy warstwy prezentacji (dostęp do baz) (pull_request) Successful in 9m29s
Testy / Testy warstwy bazodanowej (ochrona baz) (pull_request) Successful in 9m25s
Testy / Build obrazu silnika B (swisseph) (pull_request) Successful in 7s
Testy / Kontrola składni wszystkich warstw (pull_request) Successful in 6s
Testy / Testy warstwy logicznej (silnik) (push) Successful in 10m26s
Testy / Testy warstwy prezentacji (dostęp do baz) (push) Successful in 9m29s
Testy / Testy warstwy bazodanowej (ochrona baz) (push) Successful in 9m25s
Testy / Build obrazu silnika B (swisseph) (push) Successful in 7s
Testy / Kontrola składni wszystkich warstw (push) Successful in 5s
Dwa testy z PR #71 przechodziły lokalnie i padały w CI. Przyczyna nie miała nic wspólnego z badaną rzeczą: wymuszały awarię przez chmod 000 i chmod 555, a CI działa jako ROOT — root omija bity uprawnień w Linuksie, więc odczyt i zapis się udawały i asercje leciały na komunikat, którego nie było. Test zależny od tego, KTO go uruchamia, jest gorszy niż jego brak: daje fałszywe poczucie pokrycia i zapala się w miejscu niezwiązanym z tym, co sprawdza. Teraz awarię wymuszamy podmianą dokładnie tego punktu, w którym system plików mówi „nie": odczytu pliku kont (osłona przepuszcza wszystko inne, żeby szablony nadal się wczytywały) oraz mkstemp przy zapisie. To drugie jest celowe — mkstemp wywala się PIERWSZY przy katalogu tylko do odczytu, jeszcze zanim dojdzie do zapisu i podmiany, i właśnie tego dotyczyła naprawiana poprawka. Sprawdzian na PRAWDZIWYCH prawach zostaje, ale z pominięciem przy uruchomieniu z roota — jako kontrola, że podmiana odpowiada rzeczywistości, a nie tylko sama sobie. W CI się nie wykona i to jest w porządku: znaczyłby tam tyle co nic. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>