Ajouter une intégration continue à vos builds de conteneur

L’intégration continue est un processus de développement logiciel dans lequel une application est conservée dans un état continuellement disponible en fournissant des builds automatisées avec chaque validation à une base de code spécifique. Vous pouvez ajouter une intégration continue à pratiquement n’importe quel système de génération, mais deux sont particulièrement pratiques sont GitHub Actions et Azure Pipelines. Dans cette rubrique, vous allez découvrir comment utiliser GitHub Actions ou Azure Pipelines pour automatiser les étapes de génération Docker décrites dans Utiliser des conteneurs pour créer des applications Azure Sphere.

Utiliser GitHub Actions pour générer automatiquement votre conteneur

GitHub Actions vous permet d’automatiser votre processus de génération directement à partir de vos dépôts GitHub. Par conséquent, la première étape de l’utilisation de GitHub Actions consiste à créer ou à ouvrir un dépôt GitHub qui contient votre code d’application. Cette rubrique part du principe que vous avez créé un référentiel GitHub contenant l’application Blink générée dans le tutoriel : Créer une application de haut niveau et que votre projet est nommé « Blink ». Comme pour tout projet d’intégration continue, assurez-vous que votre projet est généré localement et fournit les artefacts attendus avant de tenter d’automatiser le processus. Dans cet exemple, nous partons du principe qu’après une génération réussie, le out répertoire contient un fichier Blink.imagepackage.

Dans le répertoire de niveau supérieur de votre dépôt GitHub, créez un répertoire nommé .devcontainer et créez un fichier nommé Dockerfile dans ce répertoire avec le contenu suivant :

FROM mcr.microsoft.com/azurespheresdk:latest AS dev

FROM dev AS build
COPY ./ /src/
WORKDIR /out
RUN cmake -G "Ninja" -DCMAKE_TOOLCHAIN_FILE="/opt/azurespheresdk/CMakeFiles/AzureSphereToolchain.cmake" \
    -DAZURE_SPHERE_TARGET_API_SET="latest-lts" -DCMAKE_BUILD_TYPE="Release" "/src"
ENTRYPOINT [ "ninja" ]

La ligne initiale FROM spécifie l’image Docker Azure Sphere standard en tant que conteneur de développement de base, et la deuxième indique d’utiliser ce conteneur de base comme environnement de build. La COPY ligne copie le contenu du référentiel dans le répertoire /src/ du conteneur. Spécifie WORKDIR le répertoire de build. La RUN commande fournit la commande CMake pour générer les fichiers de build. Enfin, les ENTRYPOINT spécifies que ninja doit être appelé pour générer réellement l’application.

Dans le répertoire de niveau supérieur de votre référentiel, créez le répertoire .github/workflows et ajoutez un fichier nommé ci.yml avec le contenu suivant :

# This is a basic workflow to help you get started with Actions

name: ContinuousIntegration

# Controls when the action will run. Triggers the workflow on push or pull request
# events, but including workflow_dispatch also allows manual execution
on:
  push:
  pull_request:
  workflow_dispatch:


jobs:
  build:
    runs-on: ubuntu-latest
    name: Build Azure Sphere Apps
    steps:
    - name: Checkout
      uses: actions/checkout@v2
    - name: Build image for azsphere builds and Start container from build image
      run: |
        docker build --target build -t hlbuildimage -f .devcontainer/Dockerfile .
        docker run --name hlbuildcontainer hlbuildimage
    - name: Copy container build output
      run:
        docker cp hlbuildcontainer:/out HLOutput
    - name: Publish HL imagepackage
      uses: actions/upload-artifact@v2
      with:
        name: HL imagepackage
        path: ${{ github.workspace }}/HLOutput/Blink.imagepackage

Ce flux de travail n’a qu’un seul travail pour générer l’application ; le travail s’exécute sur un exécuteur GitHub Actions, dans ce casubuntu-latest, et comporte quatre étapes :

1. L’étape 1, Checkoutest une action GitHub standard qui extrait simplement votre dépôt vers l’exécuteur ubuntu-latest.

2. L’étape 2 génère l’image (docker build) et démarre le conteneur (docker run).

3. L’étape 3 copie la sortie du conteneur vers l’exécuteur.

4. Étape 4, Publier un imagepackage HL, publie le package d’images d’application de haut niveau en tant qu’artefact.

Validez ces modifications dans votre branche principale et sélectionnez Actions. Vous devez maintenant voir une page intitulée « Tous les flux de travail », avec au moins un flux de travail en cours d’exécution ou terminé. Si le flux de travail se termine correctement, une coche verte s’affiche en regard de celle-ci. Cliquez sur un flux de travail réussi et vous devriez voir une zone intitulée « Artefacts » contenant un artefact intitulé « HL imagepackage ». Téléchargez cet artefact et décompressez le fichier imagepackage ; vous pouvez ensuite créer un déploiement ou charger une version test de l’application sur votre appareil.

Utiliser Azure Pipelines pour générer automatiquement votre conteneur

Azure Pipelines vous permet d’automatiser votre processus de génération directement à partir de vos référentiels GitHub (et de nombreux autres référentiels de code). Cette rubrique part du principe que vous appartenez déjà à une organisation avec un projet Azure DevOps et que vous avez accès à Azure Pipelines. La première étape de l’utilisation d’Azure Pipelines consiste à créer ou à ouvrir un référentiel qui contient votre code d’application. Cette rubrique part du principe que vous avez créé un référentiel GitHub contenant l’application Blink générée dans le tutoriel : Créer une application de haut niveau.

Dans le répertoire de niveau supérieur de ce référentiel, créez le répertoire .devcontainer et créez un fichier Dockerfile dans ce répertoire avec le contenu suivant :

FROM mcr.microsoft.com/azurespheresdk:latest AS dev

FROM dev AS build
COPY ./ /src/
WORKDIR /out
RUN cmake -G "Ninja" -DCMAKE_TOOLCHAIN_FILE="/opt/azurespheresdk/CMakeFiles/AzureSphereToolchain.cmake" \
    -DAZURE_SPHERE_TARGET_API_SET="latest-lts" -DCMAKE_BUILD_TYPE="Release" "/src"
ENTRYPOINT [ "ninja" ]

La ligne initiale FROM spécifie l’image Docker Azure Sphere standard en tant que conteneur de développement de base, et la deuxième indique d’utiliser ce conteneur de base comme environnement de build. La COPY ligne copie le contenu du référentiel dans le répertoire /src/ du conteneur. Spécifie WORKDIR le répertoire de build. La RUN commande fournit la commande CMake pour générer les fichiers de build. Enfin, les ENTRYPOINT spécifies que ninja doit être appelé pour générer réellement l’application.

Pour créer le pipeline :

1. Connectez-vous à votre projet Azure DevOps et ouvrez Pipelines.
2. Sélectionnez Nouveau pipeline, puis sélectionnez GitHub quand vous êtes invité à où se trouve votre code ? Vous pouvez être redirigé vers une page d’authentification GitHub ; terminez l’authentification et passez à la page pour sélectionner votre dépôt.
3. Sélectionnez votre référentiel Blink. Vous accédez à une page intitulée Configurer votre pipeline.
4. Sélectionnez Pipeline de démarrage. Cela ouvre un fichier nommé azure-pipelines.yml dans le répertoire de niveau supérieur de votre dépôt avec une tâche Hello, World.
5. Sélectionnez Enregistrer et exécuter. Acceptez le message de validation par défaut, puis sélectionnez à nouveau Enregistrer et exécuter. Le fichier azure-pipelines.yml est validé dans votre dépôt GitHub et le pipeline est créé.

Remplacez le contenu du fichier azure-pipelines.yml par le contenu suivant :

# Docker
# Build a Docker image
# https://learn.microsoft.com/azure/devops/pipelines/languages/docker

trigger:
- main

resources:
- repo: self

variables:
  tag: '$(Build.BuildId)'

stages:
- stage: Build
  displayName: Build image
  jobs:
  - job: Build
    displayName: Build
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - bash: docker build --target build -t hlbuildimage -f .devcontainer/Dockerfile . &&  docker run --name hlbuildcontainer hlbuildimage && docker cp hlbuildcontainer:/out $(Build.ArtifactStagingDirectory)/HLOutput
      displayName: Build high-level Azure Sphere application in a container and copy the output
    - task: PublishBuildArtifacts@1
      displayName: Publish build artifacts
      inputs:
        PathtoPublish: '$(Build.ArtifactStagingDirectory)/HLOutput/Blink.imagepackage'
        ArtifactName: 'BlinkSample.imagepackage'
        publishLocation: 'Container'

Ce flux de travail n’a qu’un seul travail pour générer l’application ; le travail s’exécute sur un agent Azure DevOps, dans ce casubuntu-latest, et a deux étapes :

1. L’étape 1 génère l’image (docker build), démarre le conteneur (docker run) et copie la sortie du conteneur vers l’agent.

2. Étape 2, Publier des artefacts de build, publie le package d’images d’application de haut niveau en tant qu’artefact.

Validez ces modifications dans votre branche principale. Dans Azure DevOps, ouvrez à nouveau Pipelines . Vous devriez voir une exécution de votre pipeline en cours ou simplement terminée. Si l’exécution affiche une coche verte, la build a réussi. Sélectionnez l’exécution réussie ; Vous devez voir 1 Publié dans la colonne Associée . Téléchargez cet artefact et décompressez le fichier imagepackage ; vous pouvez ensuite créer un déploiement ou charger une version test de l’application sur votre appareil.

Ajouter une intégration continue à des exemples d’applications Azure Sphere

GitHub Actions et Azure Pipelines sont destinés à automatiser les builds d’un seul projet, tels que ceux téléchargés à partir du navigateur d’exemples Microsoft. Les exemples Azure Sphere sur GitHub sont une collection de projets avec certaines ressources partagées. Pour utiliser l’un de ces exemples dans l’intégration continue, vous devez incorporer toutes les ressources partagées nécessaires. En règle générale, cela signifie au moins la création d’un répertoire HardwareDefinitions dans le répertoire de niveau supérieur de votre projet et la modification du fichier CMakeLists.txt pour pointer vers la copie locale. Par exemple, si vous créez un projet basé sur l’exemple HelloWorld/HelloWorld_HighLevelApp, le répertoire de niveau supérieur ressemble initialement à ceci :

.vscode
.gitignore
applibs_versions.h
app_manifest.json
CMakeLists.txt
CMakeSettings.json
launch.vs.json
LICENSE.txt
main.c
README.md

Le fichier CMakeLists.txt contient la ligne suivante pointant vers le répertoire HardwareDefinitions partagé dans le référentiel Samples :

azsphere_target_hardware_definition(${PROJECT_NAME} TARGET_DIRECTORY "../../../HardwareDefinitions/mt3620_rdb" TARGET_DEFINITION "sample_appliance.json")

Pour permettre à votre projet de générer, copiez le dossier HardwareDefinitions dans votre répertoire de niveau supérieur, puis modifiez le fichier CMakeLists.txt pour utiliser l’emplacement local :

azsphere_target_hardware_definition(${PROJECT_NAME} TARGET_DIRECTORY "HardwareDefinitions/mt3620_rdb" TARGET_DEFINITION "sample_appliance.json")

Là encore, vérifiez que votre projet est généré localement avant de tenter d’automatiser avec GitHub Actions.