En mai 2019, GitHub a annoncé la sortie du service Registry Registry. Suite à cela, déjà en août, un soutien pour CI / CD en Actions a été annoncé .
Dans l'article, je vais vous dire quels types de services sont et comment cela peut être utilisé sur l'exemple d'un petit projet pour animaux de compagnie sur GitHub.
De quels types de services s'agit-il?
GitHub Actions est une plateforme qui vous permet de gérer le cycle de vie du logiciel, dont le code source est hébergé sur GitHub. En fait, TravisCI, CircleCI et de nombreuses autres plateformes CI / CD gratuites ont reçu un nouveau concurrent en la personne d'Actions.
Le registre de packages GitHub est le référentiel central des artefacts; cinq types d'artefacts sont actuellement pris en charge.
Types d'artefacts pris en charge dans les actions
C'est une opportunité pratique d'avoir tous les artefacts en un seul endroit, car il n'est pas toujours conseillé de déployer votre serveur Nexus ou Artifactory.
GitHub devient de plus en plus similaire à GitLab, et quelque part il a déjà dépassé un adversaire, par exemple, GitLab ne prend pas encore en charge les packages NuGet et les gemmes Ruby. En fait, si auparavant pour les projets open source, vous deviez connecter des intégrations externes à GitHub, maintenant tous les œufs sont dans le même panier. Ici, laissez tout le monde décider si c'est bon ou mauvais, mais au moins c'est pratique.
Comment essayer?
Les deux services sont actuellement en mode bêta, vous pouvez vous inscrire pour un test bêta sur ces pages .
La migration à partir d'autres services est très simple, j'ai migré plusieurs de mes projets favoris de TravisCI et DockerHub vers Actions et Package Registry respectivement.
Je vais vous montrer à quoi cela ressemble dans un exemple. Le projet est le plus courant, j'en ai parlé dans cet article. Rien de compliqué, le code LaTeX habituel, à l'aide duquel des artefacts sont collectés (2 fichiers PDF), ils sont publiés dans les versions de GitHub. Afin de ne pas télécharger un tas de packages LaTeX, j'ai écrit un Dockerfile afin que vous puissiez travailler facilement sous n'importe quel système d'exploitation.
Registre des packages
Pour commencer à travailler avec Package Registry au lieu de DockerHub, vous devez prendre seulement deux étapes simples.
Nous créons un jeton dans les paramètres GitHub (le jeton doit avoir le droit d'écrire et de lire des artefacts).
Page de création de jeton
Et puis nous pouvons nous authentifier avec le jeton créé et pousser des artefacts, c'est aussi simple que cela:
docker login docker.pkg.github.com --username amet13 docker tag docker-latex:0.0.1 docker.pkg.github.com/amet13/master-thesis/docker-latex:0.0.1 docker push docker.pkg.github.com/amet13/master-thesis/docker-latex:0.0.1
Veuillez noter que j'ai spécifiquement indiqué mon surnom sur GitHub en minuscules, sinon vous obtiendrez une erreur de Docker:
Error parsing reference: "docker.pkg.github.com/Amet13/master-thesis/docker-latex:0.0.1" is not a valid repository/tag: invalid reference format: repository name must be lowercase
Voici à quoi cela ressemble dans l'interface Web de GitHub:
Page de registre des packages pour les images Docker
En plus des instructions pour télécharger la dernière image, des statistiques de téléchargement sont disponibles, la possibilité de télécharger une couche Docker distincte via l'interface Web, l'historique de téléchargement d'image est disponible.
Actions
Les actions sont un peu plus compliquées, mais pour ceux qui ont déjà travaillé avec un autre système CI / CD, ce ne sera pas difficile à comprendre. La configuration dans Actions est décrite par YAML déclarative, bien que HCL ait été utilisé auparavant.
Quelques concepts de base (je ne traduirai pas intentionnellement les définitions, je pense que tout est clair ici):
- Workflow - un processus qui gère le cycle de vie du logiciel (build, test, package, release, deploy) pour le référentiel
- Fichier de workflow - le fichier dans lequel le workflow est décrit, il est situé à la racine du référentiel dans le répertoire
.github/workflows/ - Le travail est à chaque exécution du workflow, le travail est déclenché, à un moment donné, beaucoup de travaux peuvent être démarrés
- Étape - chaque tâche a une étape, à chaque étape, vous pouvez exécuter des commandes ou des actions
- Action - un «plug-in» écrit par quelqu'un, une liste de nombreuses actions peut être trouvée dans le référentiel awesome-actions
- Environnement virtuel - l'environnement sur lequel Job s'exécute (en fait, c'est une machine virtuelle sous Windows, macOS ou Linux)
- Runner est un environnement déployé pour lancer un Job, un seul Job peut être exécuté sur Runner à la fois
- Événement - un événement qui déclenche le Workflow, par exemple, Push, Pull Request, Webhook, Cron Job, etc.
- Artefact - artefacts (binaires, images, journaux, etc.)
Voici à quoi ressemble la page Liste des travaux dans Workflow.
Limitations et interdictions:
- 20 workflows par référentiel
- 1 000 demandes d'API par heure pour toutes les actions du référentiel
- temps de travail maximum - 6 heures
- 20 Jobs peuvent travailler en parallèle dans le référentiel (pour tous les Workflows)
- il est interdit d'utiliser des Actions pour l'extraction de crypto-monnaie et l'informatique sans serveur
La documentation la plus récente est disponible sur ce lien .
Et voici les journaux de l'un des Job
Exemple
Revenons à l'exemple, voici à quoi ressemble ma config, nous allons l'analyser plus en détail par parties.
Spécifiez un nom pour Workflow et décrivez sur quel déclencheur il doit se déclencher (une liste de tous les déclencheurs est décrite dans la documentation ):
name: master-thesis on: [push]
Sur quel environnement virtuel exécuter le travail:
jobs: build: # ubuntu-latest, ubuntu-18.04, or ubuntu-16.04 # windows-latest, windows-2019, or windows-2016 # macOS-latest or macOS-10.14 runs-on: ubuntu-latest
La première étape, dans le name: spécifiez le nom de l'étape (facultatif), et dans uses: quelle action nous voulons utiliser, dans ce cas, clonez le référentiel:
steps: - name: Checkout repo uses: actions/checkout@v1
À l'étape suivante, nous n'utilisons pas Action, mais uniquement un ensemble de nos commandes où nous nous connectons au Registre de packages, collectons l'image Docker et la poussons dans le référentiel d'images. Dans le bloc env: définissons les variables d'environnement, nous prenons l'une d'entre elles des secrets:
- name: Build docker image and push it to the registry env: GITHUB_TOKEN: ${{ secrets.GH_TOKEN }} DOCKER_IMAGE_ORIGIN: "docker.pkg.github.com/amet13/master-thesis/docker-latex" run: | # Pull submodules git submodule init git submodule update --remote # Login to GitHub Packages and build Docker image docker login docker.pkg.github.com -u amet13 -p ${GITHUB_TOKEN} docker pull ${DOCKER_IMAGE_ORIGIN}:latest docker build -t ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} . # Generate PDF artifacts docker run --rm -i \ -v ${PWD}:/master-thesis:Z ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} \ bash -c "latexmk -xelatex -synctex=1 -jobname=master-thesis main.tex" docker run --rm -i \ -v ${PWD}:/master-thesis:Z ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} \ bash -c "cd presentation/ && latexmk -xelatex -synctex=1 -jobname=presentation main.tex" # Publish Docker image to GitHub Packages (with latest tag) docker tag ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} ${DOCKER_IMAGE_ORIGIN}:latest docker push ${DOCKER_IMAGE_ORIGIN}:${GITHUB_SHA} docker push ${DOCKER_IMAGE_ORIGIN}:latest
Je suis sûr que dans un avenir proche, une action apparaîtra qui marquera et poussera automatiquement les images au lieu d'écrire manuellement les commandes Docker.
Ajout d'un secret contenant un jeton Github
L'étape suivante après la création des fichiers PDF consiste à créer une version sur GitHub et à inclure les artefacts collectés dans cette version. Pour créer automatiquement une version, nous utilisons une action tierce , dans laquelle dans le bloc if: vous pouvez spécifier la condition de lancement de l'étape - uniquement lors de la création de la balise:
- name: Create GitHub release with artifacts uses: softprops/action-gh-release@v1 if: startsWith(github.ref, 'refs/tags/') with: files: | master-thesis.pdf presentation/presentation.pdf name: "Build ${GITHUB_SHA}" env: GITHUB_TOKEN: ${{ secrets.GH_TOKEN }}
Résumé
Malgré le statut bêta, les deux services fonctionnent bien, je suis sûr que beaucoup de choses seront terminées.
À certains moments, cela peut être gênant, il n'y a pas de variables globales, mais cela peut être fait avec des béquilles .
J'ai aimé l'approche GitHub pour abandonner HCL au profit de YAML. J'ai également aimé la prise en charge de nombreux types d'hôtes, qui sont des limites très modestes (pour l'instant), voyons comment cela se passe. En général, pour de simples pipelines dans des référentiels publics sur GitHub, un tel groupe fonctionnera très bien.
La traduction de cet article est déjà sur support .