Bien qu’une dizaine de plateformes SaaS fournissent un service d’intégration continue s’interfaçant avec Github, l’éditeur de ce dernier sentait bien qu’en ne proposant pas un service intégré comme le fait Gitlab avec Gitlab CI, il avait un trou dans la raquette. Fin 2019, l’API Github Actions s’est donc muée en véritable service de CI/CD. Le besoin de faire évoluer l’intégration continue du projet libre Hipparchus a donné l’occasion au grand fan de Gitlab CI que je suis, d’essayer ce nouveau service.

Sans surprise, les scripts Github Actions adoptent le format YAML et une syntaxe riche qui permet de configurer à loisir le processus CI/CD. La mise en œuvre du service est triviale. Il suffit de créer un script dans le répertoire .github/workflows pour que le service de CI/CD s’active.

Par rapport à Gitlab CI, les premières différences qui sautent aux yeux sont le marketplace, une collection de modèles de tâches prêtes à l’emploi, proposées par Github ou des tiers, et la possibilité de créer autant de pipelines (i.e. workflows dans le jargon de Github Actions) qu’on le souhaite.

Comme dans Gitlab CI, on retrouve dans Github Actions la notion de job, mais le terme ne correspond pas à des tâches de même granularité sur les deux plateformes. En effet, un job de Github Actions correspond plus à la notion stages de Jenkins, se décomposant en plusieurs étapes ; d’ailleurs, l’un et l’autre se découpent en steps. Tous les steps d’un job s’exécutent dans le même environnement : ce que produit un step est de facto disponible pour les steps suivants. Plusieurs jobs peuvent être définis au sein d’un workflow, mais leurs règles de déclenchement, définies au niveau global, sont les mêmes pour tous. C’est là que la possibilité de créer plusieurs workflows prend tout son sens. Ceci étant, il est tout de même possible de conditionner l’exécution d’un step à un contexte, comme je l’ai fait pour le déploiement des paquets binaires d’Hipparchus.

Si la mise en œuvre du service est simple, j’ai eu quelques difficultés à désigner les branches dans mon script jusqu’à découvrir que :

  • Le nom de la branche Git est fourni par la variable (expression dans le jargon de Github Actions) github.ref, sous la forme refs/heads/<branch> et non <branch>. Du coup, pour limiter l’exécution d’un step aux branches master et develop, il ne faut pas écrire :

      - name: Deployment
      if:  ( github.ref == 'master' ) || ( github.ref == 'develop' )
      run: ...

    mais :

      - name: Deployment
      if:  ( github.ref == 'refs/heads/master' ) || ( github.ref == 'refs/heads/develop' )
      run: ...

  • Le nom de la branche est aussi fourni, sous la même forme que github.ref, par la variable d’environnement shell GITHUB_REF. Le shell étant Bash, on peut extraire le nom de la branche de la variable GITHUB_REF via le développement ${GITHUB_REF##*/} (cf. le « développement de sous-chaine » dans la page de manuel de Bash). C’est ainsi que je désigne le nom de la branche à transmettre à SonarQube :

      - name: SonarQube scan
      run: mvn -B -f pom.xml sonar:sonar -Dsonar.login=$SONARQUBE_TOKEN -Dsonar.branch.name=${GITHUB_REF##*/}
      env:
        SONARQUBE_TOKEN: ${{ secrets.SONARQUBE_TOKEN }}

Pour le reste, la mise en œuvre du service m’a réellement paru simple et la console de suivi de l’exécution des workflows est agréable, mais n’impressionnera pas les habitués de Gitlab CI.

Si le rachat de Github par Microsoft ne me laissait aucun doute quant à la fourniture d’un environnement MS-Windows (Server 2019), GNU/Linux est bien évidemment lui aussi disponible, tant en natif (Ubuntu LTS) que via les conteneurs Docker. J’ai par contre été surpris par la disponibilité de MacOS (Catalina 10.15). Les machines virtuelles mises à disposition sont dotées de 2 cœurs, 7 Go de RAM et 14 Go de stockage SSD. Je pense que cela ne durera pas, mais Github se montre pour l’instant généreux, puisque les comptes gratuits peuvent lancer jusqu’à 20 jobs en parallèle (5 sur MacOS seulement), un job pouvant durer jusqu’à 6 heures et un pipeline jusqu’à 72 heures. À côté, Travis CI passe pour radin ! Notez que vous pouvez en outre enrôler sur cette plateforme vos propres runners auto-hébergés au cas où les configurations proposées se révèleraient trop étriquées.

Les jours des plateformes de CI/CD en mode SaaS sont comptés.