Comment publier automatiquement les versions de GitHub à partir des balises Git

Les versions de GitHub fournissent une méthode facile d’accès pour les utilisateurs finaux pour télécharger des binaires logiciels versionnés. Vous pouvez les créer manuellement, mais il est beaucoup plus facile de laisser GitHub Actions les créer automatiquement à l’aide des balises de version créées dans votre référentiel.

Utiliser des versions marquées

Les balises sont une fonctionnalité existante dans Git, avec une prise en charge étendue offerte par GitHub avec les versions, qui offrent un emplacement pour héberger des fichiers binaires avec les journaux de modifications associés.

Vous pouvez créer une balise un peu comme vous créeriez une branche, sauf qu’il s’agit d’un point fixe qui ne bouge pas et pointe toujours vers un commit spécifique. Ceci est utile pour créer des versions versionnées, et la plupart des gens créeront des balises en utilisant le format de version sémantique (Major.Minor.Patch).

Les balises peuvent être transmises à GitHub où elles peuvent être utilisées dans d’autres workflows d’automatisation. Dans ce cas, nous allons configurer un script GitHub Actions qui écoutera les commits contenant des versions étiquetées et publiera automatiquement les artefacts de construction dans une version.

Configuration des actions GitHub

Tout d’abord, vous devez vous assurer que vous disposez d’un build GitHub Actions fonctionnel et que vos scripts de build fonctionnent correctement. La configuration exacte de votre flux de travail dépendra du type de projet que vous construisez, mais généralement, vous ne voulez pas déboguer deux problèmes à la fois, vous devez donc ajouter la publication de la version une fois que vous avez déjà des artefacts fonctionnels. Vous pouvez lire notre guide pour configurer une build GitHub Actions pour en savoir plus.

La première chose à faire est de modifier la section « on » de votre script Actions pour qu’elle s’exécute également lorsque les balises sont créées. Par défaut, vous avez probablement l’événement « push » pour suivre les versions ou la branche principale. Vous devrez ajouter des balises et définir un filtre. Pour toutes les balises, utilisez simplement un caractère générique :

À la fin du workflow, une fois que tout est construit, nous créerons l’entrée Release. Il s’agit d’une étape en deux parties : d’abord, nous devrons créer un nouvel objet Release avec toutes les métadonnées, puis nous pourrons utiliser l’URL de publication générée pour télécharger les artefacts. Vous pouvez créer plusieurs étapes de téléchargement si vous disposez de plusieurs artefacts.

Dans les deux cas, nous ne souhaiterons exécuter ces étapes que si le flux de travail s’exécute à cause d’une balise. Nous pouvons le faire avec un simple if vérifier et vérifier si le github.ref object est une balise qui stocke le nom de référence de la branche ou de la balise qui a déclenché le workflow.

La première étape consiste à créer un objet Release, ce qui peut être fait à l’étape suivante. Le jeton GitHub n’a pas besoin d’être créé manuellement. Il s’agit d’un jeton spécial qui peut toujours être référencé à partir de scripts 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 }}

Notez ici que le journal des modifications pour la version est stocké à CHANGELOG.mdqui doit exister pour que le flux de travail s’exécute correctement. Vous pouvez modifier cela avec chaque balise pour modifier la démarque affichée par GitHub sur la page de publication. Il existe des outils pour générer cela automatiquement avec des messages de validation, mais la plupart des équipes auront de toute façon leur propre méthode pour gérer cela.

Ensuite, vous pouvez commencer à télécharger des artefacts. Cela utilise l’URL de téléchargement de l’étape précédente, et vous devrez définir un chemin où il peut être trouvé avec le nom d’affichage de l’actif.

     - 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

Notez ici que le type de contenu est défini sur octet-stream, ce qui est typique pour les données binaires telles que les exécutables et les DLL. Si vous publiez un ZIP ou un autre type de fichier, vous voudrez le modifier, bien que cela n’affecte que les visuels de la page de publication.

Maintenant, vous pouvez valider les modifications dans le flux de travail Actions, puis créer une nouvelle balise et la transmettre à GitHub. Vous devriez voir une nouvelle exécution de workflow en cours de création, sauf qu’au lieu de s’exécuter à partir de la branche principale, elle s’exécute à cause de la balise :

Une fois terminé, vous verrez la version dans la barre latérale GitHub.