Name: Tremplin Numérique
Price range: $$$

GitHub Actions est un puissant outil CI/CD pour exécuter des builds automatisés à partir de votre référentiel GitHub. La dernière étape de ce processus est le déploiement, qui consiste à télécharger les artefacts de build à un endroit où ils sont facilement accessibles. AWS S3 est le stockage de choix pour de nombreuses personnes et est facile à intégrer aux scripts Actions.

Pourquoi utiliser les compartiments AWS S3 pour le déploiement ?

Il convient de noter que GitHub Actions dispose d’un système de stockage d’artefacts de base, cependant, vous ne voudrez pas l’utiliser en production. C’est à des fins d’archivage et de test, et les artefacts des versions terminées expireront après 90 jours.

Il existe également des packages GitHub, conçus pour remplacer les gestionnaires de packages spécifiques à un langage, tels que JavaScript. npm. Cela peut être très utile si vous publiez un package NPM, mais n’est pas aussi utile pour d’autres types de builds.

Pour tous les autres types d’artefacts, les compartiments S3 d’Amazon restent l’un des moyens incontournables de télécharger des fichiers pour la distribution et le déploiement. Ils sont soutenus par le système d’autorisations IAM d’AWS, qui offre une excellente sécurité et est capable d’affiner les contrôles d’accès à votre code source compilé.

Alternativement, si vous utilisez des conteneurs Docker pour le déploiement, vous souhaiterez utiliser un registre de conteneurs à la place. Heureusement, GitHub dispose d’un registre privé facile à intégrer, et vous pouvez lire notre guide d’utilisation pour en savoir plus.

L’utilisation de S3 est assez simple, et la plupart des étapes présentées ici s’appliqueront également aux solutions de stockage compatibles S3, telles que Digital Ocean Spaces ou MinIO auto-hébergé, car elles utilisent la même API.

Chargement sur AWS S3 à partir d’actions GitHub

Pour commencer, vous devez vous assurer que le reste de votre script de génération GitHub Actions fonctionne et produit une version valide, car vous ne souhaitez généralement pas déboguer plusieurs problèmes à la fois.

Si vous n’en avez pas encore, la configuration dépendra de votre chaîne d’outils de build, mais vous pouvez lire notre guide de configuration des builds automatisés pour en savoir plus. Vous pouvez également tester l’artefact qui sera téléchargé à l’aide de la fonction intégrée de GitHub upload-artifact action, qui publie le contenu d’un répertoire sous forme de bundle.

Vous pouvez ensuite confirmer la création du bundle dans Résumé > Artefacts.

Une fois que vous avez une version qui n’échoue pas, vous pouvez ajouter le téléchargement S3 à la fin de celle-ci. Il n’existe pas de moyen officiel de le faire facilement, et de nombreuses solutions différentes existent sur le GitHub Actions Marketplace.

Le plus populaire est S3 Sync, qui utilise l’API S3 native pour télécharger des artefacts construits et est facile à configurer. Il existe également des wrappers simples comme s3cmd, qui vous permettent de transmettre des commandes directement à la CLI S3.

Une remarque cependant – la plupart d’entre eux reposent sur des exécuteurs hébergés Linux ou des conteneurs Docker, qui sont livrés avec les dépendances nécessaires au fonctionnement de l’interface de ligne de commande S3. Linux est ce sur quoi la majorité des builds s’exécutent, mais si vous devez utiliser Windows pour exécuter vos builds, vous devrez utiliser une action différente. Le multiplateforme que nous avons trouvé efficace est stcalica/s3-upload. Cela utilise un wrapper JavaScript qui installe le package s3cmd et fonctionne très bien sous Windows.

Une chose que vous devrez d’abord faire est de configurer GitHub Secrets pour vos jetons d’authentification AWS. Ceux-ci ne peuvent bien sûr pas être publics et devront être stockés dans les secrets du référentiel et accessibles par leur nom. Cela évite les fuites accidentelles de vos jetons et facilite la gestion des clés.

Vous pouvez lire notre guide sur l’utilisation des secrets GitHub pour en savoir plus à leur sujet, mais la principale chose qui vous est demandée est de vous diriger vers les paramètres du référentiel, puis de cliquer sur Secrets > Actions et de faire un

Ensuite, à la fin de votre script GitHub Actions, ajoutez une étape nommée « deploy », et configurez-la pour utiliser l’action s3-sync, ou celle que vous avez choisie. Vous devrez transmettre les secrets de la clé d’accès et de l’ID que vous avez configurés en tant que variables d’environnement.

    ...
    - name: Deploy To S3
    - uses: actions/checkout@master
    - uses: jakejarvis/s3-sync-action@master
      with:
        args: --acl public-read --follow-symlinks --delete
      env:
        AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: 'us-east-1'   # optional: defaults to us-east-1
        SOURCE_DIR: 'bin/Linux/net48'      # optional: defaults to entire repository
        DEST_DIR: "https://www.howtogeek.com/" # optional: defaults to root of the bucket

Avec ce flux de travail en particulier, vous pouvez également transmettre des arguments directement à s3cmd, qui peuvent être utilisés pour activer les ACL de lecture publique, par exemple. Ici, l’objet est défini sur public et l’ancien contenu de ce répertoire dans le compartiment est effacé, garantissant que tout correspond à la sortie de construction sans anciens fichiers.

Avec cela ajouté, il ne reste plus qu’à valider les modifications du script de construction et, éventuellement, à réexécuter la construction manuellement si elle ne redémarre pas automatiquement lors d’une nouvelle validation. Vous ne verrez aucune sortie de génération dans GitHub, car elle a été envoyée à S3, mais vous pouvez consulter les journaux de s3cmd à l’étape « déployer vers S3 » dans le journal de génération :

Espérons que vous verrez une sortie de journal similaire à celle ci-dessus, confirmant que le processus s’est déroulé avec succès.