Configurer l’Intégration Continue pour votre code de robot en utilisant GitHub Actions
Un aspect important du travail dans un environnement d’équipe est de pouvoir tester le code qui est poussé vers un dépôt central tel que GitHub. Par exemple, un gestionnaire de projet ou un développeur principal peut vouloir exécuter un ensemble de tests unitaires avant de fusionner sa contribution ou peut vouloir s’assurer que tout le code de la branche principale d’un dépôt est en bon état de fonctionnement.
GitHub Actions est un service qui permet aux équipes et aux individus de créer et d’exécuter des tests unitaires sur le code sur divers branches et sur les demandes de type pull Ces types de services sont plus communément appelés services «d’intégration continue», ou CI. Ce tutoriel vous montrera comment configurer des actions GitHub sur des projets de code de robot.
Note
Ce tutoriel suppose que le code robot de votre équipe est hébergé sur GitHub. Pour une introduction à Git et GitHub, s’il vous plaît consulter introduction guide.
Création de l’action
Les instructions pour exécuter le processus CI sont stockées dans un fichier YAML. Pour le créer, cliquez sur l’onglet « Actions » en haut de votre référentiel de données. Cliquez ensuite sur l’hyperlien « set up a workflow yourself ».
Vous allez maintenant être accueilli par un éditeur de texte. Remplacez tout le texte par défaut par ce qui suit:
# This is a basic workflow to build robot code.
name: CI
# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the main branch.
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# This grabs the WPILib docker container
container: wpilib/roborio-cross-ubuntu:2024-22.04
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v4
# Declares the repository safe and not under dubious ownership.
- name: Add repository to git safe directories
run: git config --global --add safe.directory $GITHUB_WORKSPACE
# Grant execute permission for gradlew
- name: Grant execute permission for gradlew
run: chmod +x gradlew
# Runs a single command using the runners shell
- name: Compile and run tests on robot code
run: ./gradlew build
Enregistrez ensuite les modifications en cliquant sur le bouton « Start commit » dans le coin supérieur droit de l’écran. Vous pouvez modifier le message de validation par défaut si vous le souhaitez. Cliquez ensuite sur le bouton vert « Commit new file ».
GitHub exécute désormais automatiquement une compilation à chaque fois qu’un commit est envoyé vers la branche principale ou qu’un pull request est ouvert. Pour surveiller l’état de toute compilation, vous pouvez cliquer sur l’onglet « Actions » en haut de l’écran.
Une analyse du fichier Actions YAML
Voici une analyse du fichier YAML ci-dessus. Bien qu’une compréhension stricte de chaque ligne ne soit pas requise, un certain niveau de compréhension vous aidera à ajouter plus de fonctionnalités et à déboguer les problèmes potentiels qui pourraient survenir.
# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the main branch.
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
Ce bloc de code dicte quand l’Action s’exécutera. Actuellement, l’action s’exécute lorsque les commits sont poussés vers la branche principale ou lorsque les pull requests sont ouvertes par rapport à la branche principale.
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest
# This grabs the WPILib docker container
container: wpilib/roborio-cross-ubuntu:2024-22.04
Chaque Action est composée d’une ou de plusieurs tâches qui s’exécutent séquentiellement (l’une après l’autre) ou en parallèle (en même temps). Dans notre exemple, il n’y a qu’une seule tâche « build ».
Nous spécifions que nous voulons que la tâche s’exécute sur une machine virtuelle Ubuntu et dans un Docker container qui contient le JDK, le compilateur C++ et les chaînes de compilation roboRIO .
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v4
# Declares the repository safe and not under dubious ownership.
- name: Add repository to git safe directories
run: git config --global --add safe.directory $GITHUB_WORKSPACE
# Grant execute permission for gradlew
- name: Grant execute permission for gradlew
run: chmod +x gradlew
# Runs a single command using the runners shell
- name: Compile and run tests on robot code
run: ./gradlew build
Each job has certain steps that will be executed. This job has four steps. The first step involves checking out the repository to access the robot code. The second step is a workaround for a GitHub Actions issue. The third step involves giving the virtual machine permission to execute gradle tasks using ./gradlew. The final step runs ./gradlew build to compile robot code and run any unit tests.
Ajout d’un Build Status Badge à un fichier README.md
Il est utile d’ajouter un badge d’état CI en haut du fichier README de votre dépôt pour vérifier rapidement l’état de la dernière version sur la principale. Pour ce faire, cliquez sur l’onglet « Actions » en haut de l’écran et sélectionnez l’onglet « CI » sur le côté gauche de l’écran. Cliquez ensuite sur le bouton « Create status badge » en haut à droite et copier le code Markdown du badge d’état.
Enfin, collez le code Markdown que vous avez copié en haut de votre fichier README, validez et envoyez vos modifications. Maintenant, vous devriez voir le badge d’état Actions GitHub sur votre page de référentiel de données principale.
