Comment télécharger sur Amazon S3 à partir des actions GitHub

GitHub Actions est un puissant outil CI/CD permettant d'exécuter des builds automatisés à partir de votre référentiel GitHub.

GitHub Actions est un puissant outil CI/CD permettant d'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 implique de télécharger les artefacts de build dans 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 comme celui de 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 tout autre type d'artefact, les compartiments S3 d'Amazon restent l'un des moyens incontournables pour télécharger des fichiers à des fins de distribution et de 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 plutôt utiliser un registre de conteneurs. 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, comme Digital Ocean Spaces ou MinIO auto-hébergé, car elles utilisent la même API.

Téléchargement vers AWS S3 à partir des actions GitHub

Pour commencer, vous devez vous assurer que le reste de votre script de build GitHub Actions fonctionne et produit une build valide, car vous ne voulez 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é en utilisant le module intégré 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. Il n'existe pas de moyen officiel de procéder 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 les artefacts créés 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 sous Linux ou des conteneurs Docker, qui sont livrés avec les dépendances nécessaires au fonctionnement de la CLI S3. Linux est le support sur lequel s'exécutent la majorité des builds, mais si vous devez utiliser Windows pour exécuter vos builds, vous devrez utiliser une action différente. Celui 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 faire en premier est de configurer les secrets GitHub 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 permet une gestion facile des clés.

Vous pouvez lire notre guide sur l'utilisation des secrets GitHub pour en savoir plus, mais la principale chose à faire est d'accéder aux paramètres du référentiel, puis de cliquer sur Secrets > Actions et de créer un

Ensuite, à la fin de votre script GitHub Actions, ajoutez une étape nommée « déployer » et configurez-la pour qu'elle utilise 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: '/' # optional: defaults to root of the bucket

Avec ce workflow 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 build et éventuellement à réexécuter la build manuellement si elle ne redémarre pas automatiquement lors d'une nouvelle validation. Vous ne verrez aucune sortie de build dans GitHub, car elle a été envoyée à S3, mais vous pouvez vérifier les journaux de s3cmd sous l'étape « déployer sur S3 » dans le journal de build :

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