Prendiamo in esempio la seguente pipeline:
trigger: none pool: vmImage: 'ubuntu-latest' steps: - script: echo hello world
Sembra piuttosto semplice, in quanto andiamo solamente a stampare sulla console il classico messaggio "Hello world". Tuttavia, stiamo specificando alla pipeline, anche se in maniera implicita, di fare il checkout del repository di git alla quale la pipeline è associata. Infatti, se controlliamo i log, troveremo qualcosa di simile al seguente:
Il task CmdLine sarà quello che stampa a tutti gli effetti il messaggio, ma appena prima di esso, ci sarà, appunto, il checkout del repo. Se andiamo a vedere i dettagli, Azure DevOps fa un checkout al commit e, per evitare anche push sul repo (comunque limitati da apposite permission), ci rimanda al detached state. Sebbene questo sia comunque uno stato più che valido di git, questo introduce dei warning nei log della pipeline simili al seguente:
You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command.
Di nuovo, questo non rappresenta un fondamentale problema, ma per gli inesperti o per i casi in cui è necessario "debuggare" una pipeline, un warning in più può fare la differenza. In questo caso, possiamo risolvere il problema esplicitando l'operazione di checkout. La pipeline si deve quindi trasformare in un qualcosa di simile:
trigger: none pool: vmImage: 'ubuntu-latest' steps: - script: git config --global advice.detachedHead false - checkout: self - script: echo hello world
Il checkout è ora scritto chiaramente e non è nemmeno la prima operazione da effettuare tra gli step del job. Infatti, appena prima del clone del repository, dobbiamo andare ad impostare la variabile detachedHead della sezione advice (i messaggi di stato) di git stesso al valore false. In questo modo, la pipeline risulterà molto più pulita ed il messaggio non comparirà più tra i log.
git -c http.extraheader="AUTHORIZATION: bearer ***" fetch --force --tags --prune --progress --no-recurse-submodules origin +239d7c9xxx:refs/remotes/origin/239d7c9xxx From https://dev.azure.com/aspitalia/net/_git/NetCore * [new ref] 239d7c9xxx -> origin/239d7c9xxx git checkout --progress --force 239d7c9xxx Note: switching to '----'.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Copiare automaticamente le secret tra più repository di GitHub
Eseguire attività con Azure Container Jobs
Effettuare il deploy di immagini solo da container registry approvati in Kubernetes
Code scanning e advanced security con Azure DevOps
Sfruttare MQTT in cloud e in edge con Azure Event Grid
Usare un KeyedService di default in ASP.NET Core 8
Eseguire le GitHub Actions offline
Migrare una service connection a workload identity federation in Azure DevOps
Definire stili a livello di libreria in Angular
Visualizzare le change sul plan di Terraform tramite le GitHub Actions
Eseguire una query su SQL Azure tramite un workflow di GitHub
Evitare (o ridurre) il repo-jacking sulle GitHub Actions
I più letti di oggi
- Utilizzare WebAssembly con .NET, ovunque
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
- Utilizzare il trigger SQL con le Azure Function
- Ottimizzazione dei block template in Angular 17
- Disabilitare automaticamente un workflow di GitHub (parte 2)