Come pubblicare automaticamente le versioni di GitHub dai tag Git
Le versioni di GitHub forniscono un metodo di facile accesso per gli utenti finali per scaricare i file binari del software con versione. Puoi crearli manualmente, ma è molto più semplice lasciare che GitHub Actions li crei automaticamente usando i tag di rilascio creati nel tuo repository.
Utilizzo di rilasci con tag
I tag sono una funzionalità esistente in Git, con il supporto esteso offerto da GitHub con le versioni, che offrono un posto per ospitare i file binari con i log delle modifiche associati.
Puoi creare un tag in modo molto simile a un ramo, tranne che è un punto fisso che non si sposta e punta sempre a un commit specifico. Questo è utile per creare rilasci con versione e la maggior parte delle persone creerà tag utilizzando il formato di versioning semantico (Major.Minor.Patch).
I tag possono essere inviati a GitHub dove possono essere utilizzati in altri flussi di lavoro di automazione. In questo caso, configureremo uno script GitHub Actions che ascolterà i commit contenenti rilasci con tag e pubblicherà automaticamente gli artefatti di compilazione in un rilascio.
Impostazione delle azioni GitHub
Innanzitutto, assicurati di avere una build di GitHub Actions funzionante e che i tuoi script di build funzionino correttamente. La configurazione esatta del tuo flusso di lavoro dipenderà dal tipo di progetto che stai costruendo, ma generalmente non vuoi eseguire il debug di due problemi contemporaneamente, quindi dovresti aggiungere la pubblicazione della versione una volta che hai già artefatti funzionanti. Puoi leggere la nostra guida alla configurazione di una build di azioni GitHub per saperne di più.
La prima cosa da fare è modificare la sezione “on” del tuo script Actions in modo che venga eseguita anche quando vengono creati i tag. Per impostazione predefinita, probabilmente hai l’evento “push” per tenere traccia delle versioni o del ramo principale. Dovrai aggiungere tag e impostare un filtro. Per tutti i tag, usa semplicemente un carattere jolly:
Alla fine del flusso di lavoro, dopo che tutto è stato creato, creeremo la voce Rilascio. Questo è un passaggio in due parti: in primo luogo, dovremo creare un nuovo oggetto Release con tutti i metadati, quindi possiamo utilizzare l’URL di pubblicazione generato per questo per caricare gli artefatti. Puoi creare più fasi di caricamento se disponi di più artefatti.
In entrambi i casi, eseguiremo questi passaggi solo se il flusso di lavoro è in esecuzione a causa di un tag. Possiamo farlo con un semplice ifcontrollo e verificare se l’ github.refoggetto è un tag, che memorizza il nome di riferimento del ramo o del tag che ha attivato il flusso di lavoro.
Il primo passaggio consiste nel creare un oggetto Release, operazione che può essere eseguita con il passaggio successivo. Il token GitHub non deve essere creato manualmente: è un token speciale a cui è sempre possibile fare riferimento dagli script di Actions.
- name: Create Release
if: startsWith(github.ref, 'refs/tags/')
uses: actions/create-release@v1
id: create_release
with:
draft: false
prerelease: false
release_name: ${{ github.ref }}
tag_name: ${{ github.ref }}
body_path: CHANGELOG.md
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Si noti qui che il registro delle modifiche per la versione è archiviato in CHANGELOG.md, che deve esistere affinché il flusso di lavoro venga eseguito correttamente . Puoi modificarlo con ogni tag per modificare il markdown visualizzato da GitHub nella pagina di rilascio. Esistono strumenti per generarlo automaticamente con messaggi di commit, ma la maggior parte dei team avrà comunque il proprio metodo per gestirlo.
Successivamente, puoi iniziare a caricare artefatti. Questo utilizza l’URL di caricamento del passaggio precedente e dovrai definire un percorso in cui può essere trovato insieme al nome visualizzato per la risorsa.
- name: Upload Release
if: startsWith(github.ref, 'refs/tags/')
uses: actions/upload-release-asset@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
upload_url: ${{ steps.create_release.outputs.upload_url }}
asset_path: Oxide.Ext.Sanctuary/bin/Release/net48/Oxide.Ext.Sanctuary.dll
asset_name: Oxide.Ext.Sanctuary.dll
asset_content_type: application/octet-stream
Si noti qui che il tipo di contenuto è impostato su octet-stream, che è tipico per i dati binari come eseguibili e DLL. Se stai pubblicando un file ZIP o un altro tipo di file, ti consigliamo di modificarlo, anche se influisce solo sulla grafica nella pagina di rilascio.
Ora puoi eseguire il commit delle modifiche al flusso di lavoro di Actions, quindi creare un nuovo tag e inviarlo a GitHub. Dovresti vedere una nuova esecuzione del flusso di lavoro in fase di creazione, tranne che invece di eseguire il ramo principale, è in esecuzione a causa del tag:
Al termine, vedrai la versione nella barra laterale di GitHub.
Lascia un commento