Al giorno d'oggi, quando parliamo di DevOps, non possiamo prescindere dall'affrontare il tema di Infrastructure As Code (IaC), in cui andiamo a definire l'infrastruttura come codice, in modo tale che sia versionata e gestita dal source control esattamente come il codice applicativo. Strumenti come Terraform, infatti, sono piuttosto diffusi, ma la loro governance diventa sempre più complessa al crescere dell'infrastruttura stessa.
Una azione che ci può venire comoda quando uniamo il mondo di Terraform con le GitHub Actions, è fare in modo di elencare le change che stiamo andando ad applicare, così che sia più facile, visivamente, capire qual è l'output di un plan senza dover necessariamente analizzare tutti i log del workflow. Supponiamo quindi di avere uno o più file Terraform e di dover fare il deploy in Azure dell'infrastruttura:
steps: - uses: actions/checkout@v4 - run: terraform init id: init env: ARM_CLIENT_ID: ${{ secrets.ARM_CLIENT_ID }} ARM_CLIENT_SECRET: ${{ secrets.ARM_CLIENT_SECRET }} ARM_TENANT_ID: ${{ secrets.ARM_TENANT_ID }} ARM_SUBSCRIPTION_ID: ${{ secrets.ARM_SUBSCRIPTION_ID }} - run: terraform fmt -check - run: terraform validate -no-color - name: Terraform Plan id: plan env: ARM_CLIENT_ID: ${{ secrets.ARM_CLIENT_ID }} ARM_CLIENT_SECRET: ${{ secrets.ARM_CLIENT_SECRET }} ARM_TENANT_ID: ${{ secrets.ARM_TENANT_ID }} ARM_SUBSCRIPTION_ID: ${{ secrets.ARM_SUBSCRIPTION_ID }} run: terraform plan -no-color
In questi primi passaggi, eseguiamo solo il clone del codice sorgente in locale e, quindi, lanciamo i comandi base di terraform per generare il piano delle modifiche che andrà ad applicare all'infrastruttura su Azure. In questo caso, non c'è una grande variazione rispetto a ciò che faremo localmente, se non che il workflow potrà essere condiviso da tutta l'organizzazione.
L'output del plan, però, rimane nascosto (a meno di utilizzare altri strumenti come Terraform Cloud o altri) all'interno del workflow, mentre sarebbe decisamente più comodo averlo disponibile su una issue o sulla pull request che ha triggerato il workflow. Per questo, è sufficiente aggiungere uno step che legge l'output dello step che ha eseguito il plan e mandarlo come risposta:
- name: Add Plan Comment uses: actions/github-script@v7 env: PLAN: "terraform\n${{ steps.plan.outputs.stdout }}" with: github-token: ${{ secrets.GITHUB_TOKEN }} script: | const output = `#### Terraform plan ??\`${{ steps.init.outcome }}\` #### Terraform Plan 📖\`${{ steps.plan.outcome }}\` Show Output \`\`\`${process.env.PLAN}\`\`\` *Pusher: @${{ github.actor }}, Action: \`${{ github.event_name }}\`, Workflow: \`${{ github.workflow }}\`*`; github.rest.issues.createComment({ issue_number: context.issue.number, owner: context.repo.owner, repo: context.repo.repo, body: output })
Con un po' di manipolazione si possono far vedere solamente le diff in markdown, piuttosto che operazioni più complesse, a nostro gusto.
L'output generato sarà simile al seguente:

Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Utilizzare Container Queries nominali
Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
Creare alias per tipi generici e tuple in C#
Recuperare automaticamente un utente e aggiungerlo ad un gruppo di Azure DevOps
Sfruttare gli embedding e la ricerca vettoriale con Azure SQL Database
Gestione dell'annidamento delle regole dei layer in CSS
Aggiornare a .NET 9 su Azure App Service
Creare un webhook in Azure DevOps
Bloccare l'esecuzione di un pod in mancanza di un'artifact attestation di GitHub
Il nuovo controllo Range di Blazor 9
Cambiare la chiave di partizionamento di Azure Cosmos DB