In ogni progetto che si rispetti ci troviamo a che fare, più o meno frequentemente, con dei rilasci. Ciascuna release deve necessariamente includere delle note di rilascio, così che sia più facilmente intuibile dagli utilizzatori finali delle nostre applicazioni cos'è cambiato, se abbiamo introdotto breaking changes, se abbiamo risolto dei problemi noti e così via. Spesso, però, la creazione delle note di rilascio è un problema poichè intercorrono tempi molto lunghi tra un rilascio ed il successivo, oppure perchè semplicemente ci si dimentica di cosa è stato fatto.
In generale, è bene sempre affidarsi ad un sistema automatico. Anche in questo caso, in GitHub, tramite la CLI è possibile sfruttare un comando particolare per generare le release notes. Vediamo un esempio:
on: push: tags: - 'v*' name: Create Release jobs: create-github-release: name: Create GitHub Release runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3.0.0 - name: Create Release run: gh release create ${{ github.ref }} --generate-notes env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Il workflow evidenziato sopra viene invocato ogni qualvolta che noi andiamo a creare un tag "v..." (per indicare una versione). E', chiaramente, solo una naming convention e ciascuno può adottare la sua oppure, in alternativa, si può pensare di fare uso di workflow_dispatch per invocare il workflow manualmente al bisogno.
Quando il processo partirà, effettuerà il checkout del codice sorgente e, successivamente, andrà a generare le note di rilascio a partire da una nuova release effettuata tramite il comando gh release create a cui viene passata la reference del commit, ovvero il tag appena creato.
Quando la release è stata creata, noi potremo raggiungerla e visualizzarla fisicamente tramite l'URL https://github.com/{organization}/{repo}/releases/tag/v{version}.
Chiaramente, essendo un processo completamente automatizzato, potrebbe generare risultati non corretti al 100%. Inoltre, il "What's changed" è stato creato a partire dalle pull request chiuse, quindi è fondamentale adottare qualche naming convention proprio a livello di team e di repository, per fare in modo che le release note siano generate in modo chiaro e comprensibile a chiunque, anche al di fuori del team di sviluppo. In ogni caso rimarranno editabili anche manualmente in un momento successivo alla creazione, qualora sia necessario intervenire puntualmente.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Generare token per autenicarsi sulle API di GitHub
Eseguire una query su SQL Azure tramite un workflow di GitHub
Sfruttare lo stream rendering per le pagine statiche di Blazor 8
Utilizzare QuickGrid di Blazor con Entity Framework
Le novità di Angular: i miglioramenti alla CLI
Disabilitare automaticamente un workflow di GitHub (parte 2)
Eseguire le GitHub Actions offline
Garantire la provenienza e l'integrità degli artefatti prodotti su GitHub
Utilizzare la versione generica di EntityTypeConfiguration in Entity Framework Core
Installare le Web App site extension tramite una pipeline di Azure DevOps
Cancellare una run di un workflow di GitHub