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
Gestire gli accessi con Token su Azure Container Registry
Il nuovo controllo Range di Blazor 9
Creare una custom property in GitHub
.NET Conference Italia 2024
Inference di dati strutturati da testo con Semantic Kernel e ASP.NET Core Web API
Change tracking e composition in Entity Framework
Generare la software bill of material (SBOM) in GitHub
Sfruttare GPT-4o realtime su Azure Open AI per conversazioni vocali
Managed deployment strategy in Azure DevOps
Eseguire query per recuperare il padre di un record che sfrutta il tipo HierarchyID in Entity Framework