Le Touilleur ExpressLe Touilleur ExpressLe Touilleur ExpressLe Touilleur Express
  • Accueil
  • A propos de l’auteur
  • A propos du Touilleur Express

GitHub Actions : le tueur de Jenkins ?

    Home Architecture GitHub Actions : le tueur de Jenkins ?

    GitHub Actions : le tueur de Jenkins ?

    Par Nicolas Martignole | Architecture | 0 commentaire | 15 février, 2021 | 0 | 953 affichages
         

    Avouez-le : ce titre de blog est super racoleur. J’avais aussi pensé à un autre titre comme « il découvre comment isoler son toit pour 1 euro avec Github Actions » ou encore « vous payez trop d’impôts ? Pensez à Github Actions« . J’en profite d’ailleurs pour vous informer que ce post n’est pas et ne sera jamais sponsorisé par Github, ou les sociétés d’isolation à un euro.

    Dis Nicolas, c’est quoi Github Actions ? Et bien c’est un système proposé par Github, qui permet d’exécuter des scripts lorsque tu commites du code code, que tu merges une branche, ou d’autres activités sur ton repo Github.

    A quoi cela sert-t-il ? Et bien en premier lieu, à automatiser certaines tâches et à ajouter des processus d’intégration continue. Vous pouvez par exemple déclencher une batterie de tests unitaires, de tests fonctionnels, lancer une migration, préparer un packaging pour Docker, mettre à jour une doc, bref tout un tas de Workflow intéressant.

    Vous pouvez donc faire de l’intégration continue ET du déploiement continu. Github Actions est gratuit pour les repos publiques jusqu’à 2000 actions par mois. C’est un service payant pour les repositories privés, intégré cependant à votre souscription. Sincèrement, c’est largement moins cher qu’un Jenkins d’entreprise partagé par 30 personnes, et qui est au bout de sa vie.

    Prenez un projet Java + Maven par exemple. Il suffit d’ajouter un fichier yaml dans le répertoire .github/workflows et de créer une action comme celle-ci :

    name: Java CI
     on: [push]
     jobs:
       build:
         runs-on: ubuntu-latest
     steps:   - uses: actions/checkout@v2   - name: Set up JDK 1.8     uses: actions/setup-java@v1     with:       java-version: 1.8   - name: Build with Maven     run: mvn --batch-mode --update-snapshots verify

    A titre d’exemple un peu plus musclé, voici le workflow que nous utilisions sur un projet interne avec Quarkus.

    # Build the Quarkus part of Timekeeper
    name: Quarkus CI on develop
    on:
      workflow_dispatch:
      push:
        branches: [ develop ]
      pull_request:
        branches: [ develop ]
    jobs:
      build-and-test-backend:
        runs-on: ubuntu-latest
        steps:
        - uses: actions/checkout@v2.3.3
        - name: Set up JDK 11
          uses: actions/setup-java@v1
          with:
            java-version: 11
        - name: Build with Maven in batch mode
          run: ./mvnw -B compile test --file pom.xml
        - name: Sonar quality
          run: ./mvnw -B -P sonar -Dsonar.login=$SONAR_TOKEN --file pom.xml clean verify sonar:sonar
          env:
            GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
            SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}      
        - name: Build failed Notification
          if: failure()
          uses: rtCamp/action-slack-notify@v2.1.0
          env:
            SLACK_TITLE: ERROR Github Msg
            SLACK_COLOR: '#ee0000'
            SLACK_CHANNEL: fr-timekeeper
            SLACK_WEBHOOK: ${{ secrets.slack }} 

    Ce build fait plusieurs choses intéressantes :

    • installation du JDK 11
    • exécution de Maven avec les tests
    • exécution de Sonar et envoi sur sonarcloud.io du résultat du build. Ceci permet de voir la « qualité » de chaque PR avant même qu’elle ne soit mergée sur main. Il faut installer l’application SonarCloud sur votre organisation Github. Et il faudra aussi un abonnement SonarCloud.io
    • Notification Slack sur le channel « fr-timekeeper ». Pour cela il faudra installer l’application Slack pour Github

    Sur ce même projet, nous avions un 2ème workflow pour compiler uniquement la partie React. Les fichiers sont placés dans le sous-répertoire /frontend. Ainsi, ce Workflow ne se réveille que lorsqu’il y a une activité sur ce sous-répertoire.

    # This workflow will do a clean install of node dependencies, build the source code and run tests across different versions of node
    name: Frontend CI
    
    on:
      push:
        branches: [ develop ]
        paths:
          - 'frontend/**'
      pull_request:
        branches: [ develop ]
        paths:
          - 'frontend/**'
    jobs:
      build-and-test-frontend:
        runs-on: ubuntu-latest
        name: Build and test frontend
        steps:
          - uses: actions/checkout@v2.3.3
          - uses: bahmutov/npm-install@HEAD
            with:
              working-directory: ./frontend
              useLockFile: false
          - run: CI=true npm test
            working-directory: ./frontend   

    Vous pouvez par exemple publier automatiquement une image Docker sur Github Container Registery.

    Comment tester les workflows Github Actions ?

    Le seul « bémol » lorsque vous mettez au point vos workflows : comment les tester ? On se retrouve à faire un commit avec un espace pour lancer le build… Hmmm c’est pourri ton isolation de toit tu sais ?

    Et là, petite découverte de mes collègues de Lunatech (Manuel Dupont et Maude Cahuet) : y’a le projet Act qui te permet de lancer en local les scripts, afin de vérifier si tout fonctionne. Je leur dis merci car c’est supra-ultra pratique. Act se base sur Docker et permet d’exécuter les workflows localement sur une image Docker. A l’heure où j’écris ces lignes, cela ne marche pas sur ARM si vous avez les derniers Apple M1 qui déboitent. Mais bon c’est une histoire de semaines je pense.

    A noter que l’option workflow_disptach vous permettra aussi de déclencher à la demande un workflow. Cela ajoute un bouton « Run Workflow » dans l’interface Web de Github. Pratique pour des workflows manuels et exceptionnels.

    En conclusion, et pour voir si vous avez bien compris

    Ce matin je vous sens en PLS donc on va faire un contrôle de connaissances.

    GitHub Actions permet :

    1. de vérifier qu’une PR compile
    2. de lancer des tests unitaires sur une PR, et de bloquer le merge si un test échoue
    3. de packager une image Docker, de la pousser sur la registery de Github
    4. de publier un message de succès sur Slack
    5. les réponses de 1 à 4

    Bref vous l’aurez compris : ce serait dommage de ne pas isoler votre code et de passer à côté de ce superbe produit, surtout si votre repo est publique !

    Bonne semaine !

    Articles similaires:

    Default ThumbnailRiviera Dev : HOW GITHUB USES GITHUB TO BUILD GITHUB Le code source du CFP de Devoxx France est sur Github Default ThumbnailLancement de Google Buzz, le tueur de Twitter ?
    architecture, ci_cd, devops, git

    Leave a Comment

    Annuler la réponse

    Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

    *
    To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
    Anti-spam image

    Chercher

    Derniers articles

    • Premier mois chez Doctolib
    • GitHub Actions : le tueur de Jenkins ?
    • Comment recréer du lien social dans l’Entreprise avec des outils numériques en 2021
    • FizzBuzz en Java et Scala (surtout Scala)
    • Scala Kata – 01

    Commentaires récents

    • Frédéric Camblor dans Comment recréer du lien social dans l’Entreprise avec des outils numériques en 2021
    • b dans FizzBuzz en Java et Scala (surtout Scala)
    • Fabien Lamarque dans Scala Kata – 01
    • Cédric Clavier dans Podcast à (re)découvrir
    • Cédric Clavier dans Podcast à (re)découvrir

    Les plus lus

    • Les revenus d’un informaticien indépendant en EURL - 85 657 affichage(s)
    • Changer la batterie d’un MacBook Pro de 2011 - 61 523 affichage(s)
    • Optional en Java 8 - 52 767 affichage(s)
    • Quelle est la différence entre volatile et synchronized ? - 50 678 affichage(s)
    • Un modèle de Product Backlog et de Sprint Backlog avec Excel - 49 228 affichage(s)
    • Redis, découverte d’un moteur clé-valeur simple et puissant - 46 645 affichage(s)
    • Comment simuler le navigateur de l'iphone avec Firefox ou Safari ? - 41 722 affichage(s)
    • serialVersionUID mythes et légendes - 36 410 affichage(s)
    • Faut-il gérer une équipe de développeurs ? - 34 776 affichage(s)
    • Développeur après 31 ans ? Ridé et chauve tu seras - 34 192 affichage(s)

    Mots clés

    agile ajax Apple architecture barcamp BarCampJavaParis ddd devoxx esb exo flex geek google grails groovy humeur humour independant iphone Java javascript jazoon jboss jboss seam jsf jug Linux mac mule parisjug paris jug pjug play playframework portlet recrutement ria Scala scrum spring Startup usi usi2010 web xebia

    Recent Posts

    • Doctolib developer

      Premier mois chez Doctolib

      Je vous propose de partager mon bilan après un mois chez Doctolib,

      11 avril, 2021
    • GitHub Actions : le tueur de Jenkins ?

      Avouez-le : ce titre de blog est super racoleur. J’avais aussi pensé

      15 février, 2021
    • Comment recréer du lien social dans l’Entreprise avec des outils numériques en 2021

      Nous sommes en février 2021 pendant le 3ème confinement lié à la

      10 février, 2021

    Recent Tweets

    • RT  @axellelemaire : ☑️Se faire réveiller par une matinale sur les vertus de l’#opendata et #opensource, qui ont permis de créer  @covidtracke …

      9 hours ago
    •  @Keruspe  🍿🍿🍿😎

      24 hours ago
    • RT  @fcamblor : Mercredi je parlais d'une webapp avec du lit-element/vitejs qui partirait en prod en moins de 48h ... https://t.co/cFJIwV7og…

      1 day ago
    •  @fcamblor  Bravo Fred 👍🏻

      1 day ago
    •  @jylls35   @ponceto91  Le 6128

      1 day ago

    Mots clés

    agile (18) ajax (11) Apple (11) architecture (6) barcamp (5) BarCampJavaParis (5) ddd (5) devoxx (33) esb (6) exo (6) flex (9) geek (5) google (11) grails (5) groovy (10) humeur (12) humour (7) independant (6) iphone (12) Java (77) javascript (7) jazoon (28) jboss (22) jboss seam (12) jsf (9) jug (16) Linux (11) mac (6) mule (5) parisjug (7) paris jug (22) pjug (6) play (8) playframework (6) portlet (5) recrutement (6) ria (8) Scala (21) scrum (44) spring (23) Startup (11) usi (21) usi2010 (9) web (16) xebia (7)

    Le Touilleur Express

    Contactez-moi : nicolas@touilleur-express.fr

    Suivez-moi sur Twitter : @nmartignole

    Copyright© 2008 - 2020 Nicolas Martignole | Tous droits réservés
    • A propos de l’auteur
    • A propos du Touilleur Express
    Le Touilleur Express