Skip to main content

Workflows

· 5 min read

Un workflow est l'élément central de GitHub Actions. Il s'agit d'un processus automatisé composé de jobs et de steps qui s'exécutent sur des runners. Les workflows sont déclenchés par des événements, tels que des pushs, des pull requests, des forks, etc.

Pour créer un fichier de workflow, il faut créer un fichier .yml dans le dossier .github/workflows du dépôt. Un workflow est composé de jobs et de steps. Un job est une suite d'étapes qui s'exécutent sur le même runner, tandis qu'un step est une tâche individuelle qui peut s'exécuter dans un job. Chaque job est exécuté dans un environnement dédié défini par runs-on.

name: CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run a one-line script
        run: echo Hello, world!
      - name: Run a multi-line script
        run: |
          echo Add other actions to build,
          echo test, and deploy your project.

Documentation Complète : https://docs.github.com/en/actions/learn-github-actions/introduction-to-github-actions

Déclenchement des actions​

Les déclencheurs de workflow sont des événements qui entraînent l’exécution d’un workflow. La syntaxe dépend du niveau de précision

  • Pour tout ce qui concerne un événement :
    on: [push] # pull_request, fork etc
  • Pour plus de finesse sur l’événement :
    on: # trigger
      label: # type d'event (push, fork, pull_request)
        types:
          - created # trigger à chaque fois qu'un label est créé
      push:
        branches:
          - main # tous les push sur la branche main
  • Déclenchement manuel de l’opération (avec prise d’argument)
    on:
      workflow_dispatch:
        inputs:
          test_mode:
            description: 'True or False'
            required: true

La liste complète des déclencheurs est disponible dans la Documentation Github

Une exécution de workflow est composée d’un ou de plusieurs jobs, qui s’exécutent en parallèle par défaut. Chaque job est constitué d’un name et d’au moins un step pour être exécutable et peut être configuré. La documentation précise des job est disponible dans la Documentation Github

Marketplace​

Chaque job permet d’exécuter un script. Le script le plus basique est un simple run avec des commandes bash derrière. Cependant, il est possible de réutiliser des actions définies dans le marketplace. Par exemple le steps ci-dessous permet d’exécuter l’action https://github.com/ros-tooling/action-ros-ci. Le mot clé with permet de passer des paramètres à l’action.

danger

Le marketplace permet de réutiliser des actions déjà définies par la communauté. Il est important de vérifier la source de l’action avant de l’utiliser.

steps:
    - name: build and test ROS 2
    uses: ros-tooling/action-ros-ci@v0.2
    with:
        package-name: github-action-test
        target-ros2-distro: ${{ matrix.ros_distribution }}
        import-token: ${{ secrets.GITHUB_TOKEN }} # token autogenerated par github

Réutiliser les Workflows et Actions​

Il est possible de réutiliser des workflows et des actions dans un workflow. Pour cela, il est possible de créer des workflows et des actions dans des fichiers séparés et de les appeler dans le workflow principal.

jobs:
    workflow: # réutilisation du workflow
      uses: path/to/your-workflow.yml@v1
    action: # réutilisation d'une action
      runs-on: ubuntu-latest
      container: ubuntu:latest
      steps:
        - uses: path/to/your-action@v1

Documentation des wokflows réutilisables

Documentation des actions réutilisables

info

Lorsqu'un workflow est réutilisé il défini son propre environnement (runner, container, etc). De plus il n'est pas utilisable dans une step.

À l'inverse, une action est utilisable dans une step et fonctionne dans l'environnement du job qui l'appelle.

Type de machine​

Utilisez jobs.<job_id>.runs-on pour définir le type de machine sur laquelle le travail doit être exécuté. La configuration prend en argument un tag défini pour les runners

jobs:
    name-job:
    runs-on: ubuntu-latest # runner distant sur les serveur de Github
    runs-on: self-hosted # runner local
    steps:
        - run: echo "Hello World !"

Les runners distants fourni par Github consomment du temps pour l’organisation dans les limites de 2 000 minutes gratuites par mois. Il est préférable d’utiliser des runners self hosted (voir https://docs.github.com/fr/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners)

Le choix du runner se fait via les tags. Toutes les machines auto-hébergées partagent le tag self-hosted , le tag de leur système d’exploitation (Linux, Windows), leur architecture (x64) et des tags personnalisés par machine.

Container​

L’utilisation d’un container permet de créer un nouveau conteneur permettant d’exécuter les étapes d’un travail dans un conteneur spécififé. Si vous ne définissez pas de container, toutes les étapes s’exécutent directement sur l’hôte spécifié par runs-on dans le cas d’une machine auto-hébergées, il n’y a donc accès qu’aux packages installés sur la machine. Un container est rattaché à un job.

jobs:
    name-job:
    runs-on: self-hosted
    container:
    image: ubuntu:jammy # run job with ubuntu:jammy docker
        steps:
            - run: echo "Hello World !"

Strategy​

L’utilisation de strategy permet créer automatiquement plusieurs exécutions de travaux basées sur des combinaisons de variables. Une stratégie de matrice est utile pour tester du code dans différentes versions d'un langage ou sur différents systèmes d'exploitation. Par exemple

jobs:
    example_matrix:
    strategy:
        matrix:
        version: [10, 12, 14]
        os: [ubuntu-latest, windows-latest]
        steps:
            - run : echo "${{ matrix.version }} ${{ matrix.os }}"

Un travail s’exécute pour chaque combinaison possible des variables. Dans cet exemple, le workflow exécute six travaux, un pour chaque combinaison des variables os et version.

Artéfact​

Les artefacts permettent de conserver des données une fois un travail terminé et de les partager avec une autre action. Un artefact est un fichier ou une collection de fichiers générés pendant l’exécution d’un workflow. Cet exemple permet de stocker un fichier comme artefact.

- name: Archive code coverage results
    uses: actions/upload-artifact@v3
    with:
        name: code-coverage-report
        path: output/test/code-coverage.html

Pour récupérer un artefact

- name: Download math result for job 2
    uses: actions/download-artifact@v3
    with:
        name: homework

Vrac​

0%