Comment bien débuter avec GitHub Actions

Dans cet article nous revenons sur les principales fonctionnalités d’Actions, l’outil CI/CD inclus dans les dépôts GitHub. Nous y présentons également un tutoriel pour configurer manuellement ses propres workflows Terraform, couplé à Microsoft Azure.

GitHub a multiplié les annonces en direction de la communauté des développeurs ces derniers mois. En août 2019, le spécialiste de l’hébergement de dépôts avait présenté GitHub Actions. La disponibilité générale a suivi en novembre de la même année. Cette fonctionnalité a encore profité d’une mise en avant lors de la présentation du tiers gratuit étendu. Aujourd’hui l’éditeur affirme que c’est la fonctionnalité CI la plus utilisée par les développeurs sur GitHub.

Suite de l'article ci-dessous

Actions, c’est la composante CI/CD de GitHub développée en Go. Son grand intérêt repose dans l’intégration native avec la plateforme de dépôt de codes. La promesse : construire, tester et déployer du code sur « n’importe quel OS » (Windows, Linux et macOS) en utilisant des langages comme NodeJs, Python, Java, PHP, Ruby, .Net ou encore Go. Il est possible de lancer ces opérations dans des VM ou des containers. Ces jobs sont administrés depuis des machines hébergées et gérées par GitHub. Ils sont nommés « runners ». Il est également possible d’héberger ses propres runners, et donc d’éviter la facturation de GitHub, mais les entreprises qui choisissent cette option doivent éviter leur connexion avec des dépôts publics pour des raisons de sécurité.

Afin de réduire les menaces, GitHub détruit les VMs à la fin d’une tâche d’automatisation. Selon Edward Thomson, Product Manager chez GitHub, l’éditeur a d’abord envisagé d’utiliser des fonctions programmatiques de type serverless, mais « certains workloads demandent une puissance de calcul conséquente qui n’est pas disponible avec un service FaaS », déclare-t-il.

Toutefois, GitHub s’est inspiré de son fonctionnement pour activer et détruire les VMs à la volée. En conséquence, GitHub Actions est facturé à la minute. Si le run dure moins d’une minute (et c’est souvent le cas pour les opérations basiques), cette minute vous sera tout de même déduite. Ainsi la version gratuite propose 2 000 actions/workflows par mois pour 500 Mo de stockage.

Les fonctionnalités principales de GitHub Actions

Le déploiement d’un pipeline Actions peut découler d’une configuration manuelle, c’est-à-dire l’édition de deux fichiers YAML associés à un dépôt ou le choix d’une recommandation effectuée par GitHub. L’outil de l’éditeur analyse le code (plus précisément les éléments programmés dans les langages mentionnés ci-dessus) pour proposer quelques templates d’intégration continue vers des services spécifiques comme Azure, Google Kubernetes Engine, ou AWS.

Pour le développeur, la fonctionnalité est disponible depuis la page principale du dépôt, à côté de l’onglet Pull requests.

En cliquant sur le bouton Actions, vous devez ajouter des worflows via l’onglet associé, ensuite vous pouvez choisir la proposition suggérée ou les suivantes présentées plus bas. Déployer du code NodeJS dans une Web App Azure, déployer un container ECS sur Fargate ou EC2, construire un container Docker, le publier dans Google Container Registery pour ensuite l’exécuter sur GKE…

En déployant votre premier dépôt, GitHub vous met à disposition 15 templates d’Actions, nommés « starter workflows ». L’outil génère le fichier YAML, vous l’éditez pour ajouter vos identifiants vers les différents services appelés pendant l’opération et vous validez votre configuration avec le bouton Commit dans la branche de votre choix. Un indicateur vert vous indique si votre workflow a fonctionné.

Vous pouvez accéder à la build depuis la fenêtre Actions. En cas d’erreur, vous pouvez relancer la procédure ou réviser les éléments d’authentification, et vous recevez un mail ou un message sur Slack, par exemple. Si vous vous connectez à un service cloud, vous verrez les ressources déployées sur le cloud associé.

L’éditeur propose une marketplace associée à Actions afin de retrouver d’autres templates de workflow pour les déploiements, les tests, mais également la gestion des dépôts. Plus de 3 800 contributeurs dont des éditeurs comme Hashicorp proposent des intégrations CI/CD avec GitHub Actions. Une catégorie est particulièrement populaire : la gestion des issues.

Celle-ci nous permet d’introduire une fonctionnalité importante de GitHub Actions. Les déclencheurs de workflows. En effet, il est possible de déclencher des actions automatiques suivant des conditions particulières. Dans le cas des issues, le template « Create Issue Branch » permet de créer automatiquement une branche après avoir assigné une Issue à un développeur.
Un autre modèle convertit les commentaires Todo en Issues, qui pourront être documentées par l’ensemble d’une équipe. Ces composants demandent d’éditer manuellement le fichier YAML de votre action en copiant le code proposé depuis la marketplace.

Comment déployer son propre workflow : un exemple avec Azure et Terraform

Justement, en parlant d’approche manuelle, il est temps d’expliquer comment configurer manuellement un workfow GitHub Actions.

Ici nous voulons pousser du code Terraform (HCL ou JSON) dans Microsoft Azure en utilisant la fonctionnalité.

La première étape consiste à créer et à nommer votre dépôt GitHub. Ensuite, il faut le cloner via le bouton associé.

Ici nous utilisons VS Code, l’IDE nativement compatible avec Azure. Il faut bien sûr l’installer auparavant. Nous configurons le répertoire courant :

PS  C:\Users\Name\ cd.\Desktop>

Puis, nous y plaçons notre clone de dépôt :

PS  C:\Users\Name\ cd.\Desktop\ https://github.com/name/namerepo.git

Cloning into ‘namerepo’…

remote : Enumerating objects : 3, done.

Remote : Configuring objects : 100% (3/3), done.

Remote : Total 3 (delta 0), reused 0 (delta 0), pack-reused 0

Unpacking objects : 100% 3/3, done.

PS  C:\Users\Name\ cd.\Desktop\namerepo >

Puis, il faut ouvrir le clone du dépôt depuis VS Code. Celui-ci est bien vide hormis un fichier README.md.

À partir de ce moment-là, vous devez créer deux fichiers de configurations : main.tf et variables.tf.

Ceux-ci représentent un groupe de ressources et permettent de s’identifier et de connecter GitHub et Microsoft Azure via Terraform.

GitHub Actions permet de déployer le code Terraform au sein de notre dépôt. Dans VS Code, nous créons notre fichier main.tf en commençant par configurer les identifiants.

provider         « azurem » {

version                   = « 1.38.0 »

subscritption_id          = var.sub

client_id                 = xxx xxxxx xxxxx xxxx xxx

tenand_id                 = xxx xxxxx xxxxx xxxx xxx

}

Dans l’optique de la démonstration, nous utilisons notre client_secret en dur, ce qui n’est pas recommandé en production.

Nous créons ensuite notre fichier variable.tf que nous remplissons de cette manière :

variable  « sub » {

   type         =  string

   default      =  xxxxx xxxxx x xxxxxx



variable “client_secret” {

    type     = string

    default  = xxxxxxxxxxxxxxxxxxxxxx

}

De retour sur l’onglet main.tf de notre VS Code, nous y ajoutons nos ressources comme ceux-ci :

 

resource “azurem_resource_group”  “DevRG” {

   name = “namerepo”

   location = “westeurope”

 

   tags = {

     environment  = “Dev”

   }

{

De retour dans le dépôt GitHub, nous appuyons sur le bouton Actions. De là, nous sélections l’onglet « set up a workflow yourself ». Nous éditons le fichier YAML généré pour retirer les lignes 11 à 17, nous changeons le nom en ligne 1 « deploy azure resource group ». À chaque fois qu’il y aura un nouveau commit, un changement dans notre code Terraform, cela exécutera GitHub Actions. Nous allons construire et déployer notre workflow sur Ubuntu. Puis, nous définissons quatre étapes : la vérification du format, l’initialisation, la planification, pour vérifier la présence d’erreur ou non, et l’application de Terraform.

Le code se présente comme cela :

name: deploy azure resource source

 

on: [push]

 

jobs:

  build-and-deploy:

    runs-on: ubuntu-latest

   

  steps:

 - name: "Checkout"

   uses: actions/checkoutmaster

 - name: "Terraform Format"

   uses: hashicorp/terraform-github-actionsmaster

   with:

    tf_actions_version: 0.12.13

    tf_actions_subcommand : "fnt"

  

 - name: "Terraform Init"

   uses: hashicorp/terraform-github-actionsmaster

   with:

    tf_actions_version: 0.12.13

    tf_actions_subcommand : "init"

   

 - name: "Terraform Plan"

   uses: hashicorp/terraform-github-actionsmaster

   with:

    tf_actions_version: 0.12.13

    tf_actions_subcommand : "plan"

     

 - name: "Terraform Apply"

   uses: hashicorp/terraform-github-actionsmaster

   with:

    tf_actions_version: 0.12.13

    tf_actions_subcommand : "apply"

 

Puis, il suffit de commit pour créer le fichier qui sera automatiquement placé dans le dépôt GitHub. Cela crée une nouvelle action, mais elle va échouer parce que nous n’avons pas ajouté de code dans nos fichiers Terraform.

Revenons à notre dépôt cloné et VS Code. La succession de touche Ctrl+Shift+F vous permet d’autoformater votre code dans main.tf.

Maintenant, ajoutons notre code avec les deux commandes git ci-dessous dans le terminal :

PS  C:\Users\Name\ cd.\Desktop\namerepo> git add .

PS  C:\Users\Name\ cd.\Desktop\namerepo> git commit –m “Commit Terraform code”

[master 64c1ad6] Commit Terraform Code

 2 files changed, 25 insertions(+)

 create mode 100644 main.tf

 create mode 100644 variables.tf

PS  C:\Users\Name\ cd.\Desktop\namerepo>

Pour éviter les conflits entre le contenu de notre dépôt et notre pipeline YAML, nous utilisons la commande git pool.

PS  C:\Users\Name\ cd.\Desktop\namerepo> git pull

remote : Enumerating objects : 6, done.

remote : Configuring objects : 100% (6/6), done.

remote : Total 5 (delta 0), reused 0 (delta 0), pack-reused 0

Unpacking objects : 100% 5/5, done.

From https://github.com/name/namerepo

 D678fbd. 4a4f42b master  -> origin/master

Merge by the ‘recursive’ strategy.

 .github/workflows/main.yml | 34 ++++++++++++++++++++++++++++++++++

 1 file changed, 34 insertions (+)

 Create mode 100644 .github/workflows/main.yml

PS  C:\Users\Name\ cd.\Desktop\namerepo>

Maintenant, place à la commande git push dont voici le résultat : 

PS  C:\Users\Name\ cd.\Desktop\namerepo> git push

Counting objects: 100% (8/8), done.

Delta compression using up to 12 threads

Compression objects: 100% (6/6), done.

Writing objects : 100% (6/6), 992 bytes | 992.00 Kib/s, done.

Total 6 (delta 1), reused 0 (delta 0)

remote: Revolving deltas: 100% (1/1) done.

To https://github.com/name/namerepo.git

   4a4f42b..77207e master -> master

PS  C:\Users\Name\ cd.\Desktop\namerepo>

De retour, dans GitHub, nous nous apercevons dans l’onglet workflow que GitHub Actions a créé un container, notre code est vérifié, le format, tandis que l’initialisation est effectuée. Bref, il a suivi les quatre étapes indiquées dans le fichier YAML. Dans Azure Portal, nous vérifions que notre groupe de ressource est bien commissionné dans notre espace cloud.

Pour approfondir sur Outils de développement

Close