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.