Nello script precedente abbiamo visto quanto sia importante per i test creare una reportistica prima di far fermare, eventualmente, il workflow. Oggi, invece, vediamo come può essere utile condividere il summary sugli utenti finali, ovvero quelli che hanno invocato il workflow, per esempio, a seguito della creazione di una pull request.
Quello che manca nell'esempio sotto è la generazione del report stesso a valle dell'esecuzione dei test: dipende infatti principalmente dalla tipologia di test (unit, security, integration, UI etc.) piuttosto che dal formato scelto (OpenCover, Cobertura, JaCoCo etc.). Tuttavia, potremo dare qualche esempio in un prossimo articolo.
Supponendo che questo report sia già stato generato, vediamo l'esempio seguente.
steps: - name: Create summary shell: pwsh run: | # TODO: parse the outcome of the unit tests... mkdir ${{ github.workspace }}/.test-results "# Integration Test Summary" >> ./.test-results/summary.md "| **Outcome** | **Total** | **Executed** | **Passed** | **Error** | **Failed** |" >> ./.test-results/summary.md "|--------|---------|---------|--------|--------|--------|" >> ./.test-results/summary.md "| $Outcome | $Total | $Executed | $Passed | $Error | $Failed |" >> ./.test-results/summary.md - name: Comment on PR with tests report uses: marocchino/sticky-pull-request-comment@v2 if: github.event_name == 'pull_request' with: header: Tests report path: '${{ github.workspace }}/.test-results/summary.md'
Nel primo passaggio, andiamo a creare un (finto, in questo caso) file di summary. In uno scenario reale, questo viene riempito con i valori che arrivano proprio dal report. E' importante il formato del file scelto, in questo caso markdown, perchè nel passaggio successivo andiamo proprio a caricare questo file come commento nella pull request che ha fatto partire questo workflow. Chiaramente se non abbiamo bisogno di struttura possiamo usare anche testo semplice, ma in alternativa, come in questo caso dove popoliamo una tabella, viene più comodo renderizzare il contenuto tramite markdown o HTML.
La creazione del commento viene fatta da una action di terze parti, chiamata sticky-pull-request-comment, che va proprio a prendere il file di summary e lo carica nella pull request che ha invocato il workflow. Il risultato finale sarà simile al seguente:
![](https://www.dopsitalia.com/script/images/73.jpg)
Da notare come l'utente con il quale è stato generato il commento è il github-bot, sintomo che è stato usato il token di default delle GitHub Action. Tuttavia, questo è personalizzabile per impersonare, eventualmente, un altro utente.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Utilizzare Copilot con Azure Cosmos DB
Installare le Web App site extension tramite una pipeline di Azure DevOps
Eseguire una query su SQL Azure tramite un workflow di GitHub
Visualizzare le change sul plan di Terraform tramite le GitHub Actions
Come EF 8 ha ottimizzato le query che usano il metodo Contains
Esportare ed analizzare le issue di GitHub con la CLI e GraphQL
C# 12: Cosa c'è di nuovo e interessante
Generare token per autenicarsi sulle API di GitHub
Eseguire le GitHub Actions offline
Eseguire attività pianificate con Azure Container Jobs
Sostituire la GitHub Action di login su private registry
Criptare la comunicazione con mTLS in Azure Container Apps