Freigeben über

Hinzufügen einer kontinuierlichen Integration zu Ihren Containerbuilds

  • Artikel

Wichtig

Dies ist die Dokumentation zu Azure Sphere (Legacy). Azure Sphere (Legacy) wird am 27. September 2027 eingestellt, und Benutzer müssen bis zu diesem Zeitpunkt zu Azure Sphere (integriert) migrieren. Verwenden Sie die Versionsauswahl oberhalb des Inhaltsverzeichniss, um die Dokumentation zu Azure Sphere (Integriert) anzuzeigen.

Die kontinuierliche Integration ist ein Softwareentwicklungsprozess, bei dem eine Anwendung in einem kontinuierlich wiederverwendbaren Zustand gehalten wird, indem automatisierte Builds mit jedem Commit auf eine bestimmte Codebasis bereitgestellt werden. Sie können praktisch jedem Buildsystem eine kontinuierliche Integration hinzufügen, aber zwei besonders praktisch sind GitHub-Aktionen und Azure-Pipelines. In diesem Thema erfahren Sie, wie Sie entweder GitHub-Aktionen oder Azure-Pipelines verwenden, um die in "Verwenden von Containern" beschriebenen Docker-Buildschritte zum Erstellen von Azure Sphere-Apps zu automatisieren.

Verwenden von GitHub-Aktionen zum automatischen Erstellen Ihres Containers

Mit GitHub-Aktionen können Sie Ihren Buildprozess direkt aus Ihren GitHub-Repositorys automatisieren. Daher besteht der erste Schritt bei der Verwendung von GitHub-Aktionen darin, ein GitHub-Repository zu erstellen oder zu öffnen, das Ihren Anwendungscode enthält. In diesem Thema wird davon ausgegangen, dass Sie ein GitHub-Repository erstellt haben, das die blink-Anwendung enthält, die im Lernprogramm generiert wurde: Erstellen Sie eine allgemeine Anwendung und ihr Projekt heißt "Blink". Stellen Sie wie bei jedem kontinuierlichen Integrationsprojekt sicher, dass Ihr Projekt lokal erstellt wird und die erwarteten Artefakte bereitstellt, bevor Sie versuchen, den Prozess zu automatisieren. In diesem Beispiel wird davon ausgegangen, dass das out Verzeichnis nach einem erfolgreichen Build eine Blink.imagepackage-Datei enthält.

Erstellen Sie im Verzeichnis der obersten Ebene Ihres GitHub-Repositorys ein Verzeichnis mit dem Namen .devcontainer, und erstellen Sie eine Datei namens Dockerfile in diesem Verzeichnis mit dem folgenden Inhalt:

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" ]

Die erste FROM Zeile gibt das standardmäßige Azure Sphere Docker-Image als Basisentwicklungscontainer an, und die zweite gibt an, diesen Basiscontainer als Buildumgebung zu verwenden. Die COPY Zeile kopiert den Inhalt des Repositorys in das Verzeichnis "/src/" des Containers. Das WORKDIR Buildverzeichnis wird angegeben. Der RUN Befehl stellt den Befehl "CMake" bereit, um die Builddateien zu generieren. Schließlich gibt die ENTRYPOINT Specifies an, dass Ninja aufgerufen werden soll, um die Anwendung tatsächlich zu erstellen.

Erstellen Sie im Verzeichnis der obersten Ebene Ihres Repositorys das Verzeichnis ".github/workflows", und fügen Sie eine Datei mit dem Namen ci.yml mit dem folgenden Inhalt hinzu:

# 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

Dieser Workflow hat nur einen Auftrag – um die Anwendung zu erstellen; der Auftrag auf einem GitHub Actions runner ausgeführt wird, in diesem Fall ubuntu-latest, und hat vier Schritte:

  1. Schritt 1, Checkoutist eine standardmäßige GitHub-Aktion, die Einfach Ihr Repository auf den ubuntu-neuesten Runner auscheckt.

  2. Schritt 2 erstellt das Image (docker build) und startet den Container (docker run).

  3. Schritt 3 kopiert die Ausgabe aus dem Container in den Läufer.

  4. Schritt 4, Veröffentlichen von HL-Imagepackage, veröffentlicht das allgemeine Anwendungsimagepackage als Artefakt.

Übernehmen Sie diese Änderungen an Ihrer Hauptzweigung, und wählen Sie "Aktionen" aus. Nun sollte eine Seite mit der Bezeichnung "Alle Workflows" angezeigt werden, wobei mindestens ein Workflow ausgeführt oder abgeschlossen ist. Wenn der Workflow erfolgreich abgeschlossen ist, wird daneben ein grünes Häkchen angezeigt. Klicken Sie auf einen erfolgreichen Workflow, und Sie sollten ein Feld mit der Bezeichnung "Artefakte" mit einem Artefakt mit der Bezeichnung "HL imagepackage" sehen. Laden Sie dieses Artefakt herunter, und entpacken Sie die Imagepackage-Datei; Sie können dann eine Bereitstellung erstellen oder die Anwendung auf Ihr Gerät querladen.

Verwenden von Azure Pipelines zum automatischen Erstellen Ihres Containers

Mit Azure Pipelines können Sie Ihren Buildprozess direkt aus Ihren GitHub-Repositorys (und vielen anderen Coderepositorys) automatisieren. In diesem Thema wird davon ausgegangen, dass Sie bereits zu einer Organisation mit einem Azure DevOps-Projekt gehören und Zugriff auf Azure-Pipelines haben. Der erste Schritt bei der Verwendung von Azure Pipelines besteht darin, ein Repository zu erstellen oder zu öffnen, das Ihren Anwendungscode enthält. In diesem Thema wird davon ausgegangen, dass Sie ein GitHub-Repository erstellt haben, das die blink-Anwendung enthält, die im Lernprogramm generiert wurde: Erstellen einer allgemeinen Anwendung.

Erstellen Sie im Verzeichnis der obersten Ebene dieses Repositorys das .devcontainer-Verzeichnis, und erstellen Sie eine Dockerfile-Datei in diesem Verzeichnis mit dem folgenden Inhalt:

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" ]

Die erste FROM Zeile gibt das standardmäßige Azure Sphere Docker-Image als Basisentwicklungscontainer an, und die zweite gibt an, diesen Basiscontainer als Buildumgebung zu verwenden. Die COPY Zeile kopiert den Inhalt des Repositorys in das Verzeichnis "/src/" des Containers. Das WORKDIR Buildverzeichnis wird angegeben. Der RUN Befehl stellt den Befehl "CMake" bereit, um die Builddateien zu generieren. Schließlich gibt die ENTRYPOINT Specifies an, dass Ninja aufgerufen werden soll, um die Anwendung tatsächlich zu erstellen.

Führen Sie zum Erstellen der Pipeline

  1. Melden Sie sich bei Ihrem Azure DevOps-Projekt an, und öffnen Sie Pipelines.
  2. Wählen Sie "Neue Pipeline" und dann "GitHub " aus, wenn Sie gefragt werden, wo befindet sich Ihr Code? Möglicherweise werden Sie zu einer GitHub-Authentifizierungsseite weitergeleitet; schließen Sie die Authentifizierung ab, und fahren Sie mit der Seite fort, um Ihr Repository auszuwählen.
  3. Wählen Sie Ihr Blink-Repository aus. Sie werden zu einer Seite mit dem Titel "Konfigurieren Der Pipeline" weitergeleitet.
  4. Wählen Sie Starterpipeline aus. Dadurch wird eine Datei namens azure-pipelines.yml im Verzeichnis der obersten Ebene Ihres Repositorys mit einer Hello, World-Aufgabe geöffnet.
  5. Klicken Sie auf Speichern und ausführen. Übernehmen Sie die Standard-Commit-Nachricht, und wählen Sie erneut " Speichern" und "Ausführen" aus. Die azure-pipelines.yml Datei wird an Ihr GitHub-Repository gebunden, und die Pipeline wird erstellt.

Ersetzen Sie den Inhalt der azure-pipelines.yml Datei durch den folgenden Inhalt:

# 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'

Dieser Workflow hat nur einen Auftrag – um die Anwendung zu erstellen; der Auftrag wird auf einem Azure DevOps-Agent ausgeführt, in diesem Fall ubuntu-latestund hat zwei Schritte:

  1. Schritt 1 erstellt das Image (docker build), startet den Container (docker run), und kopiert die Ausgabe aus dem Container in den Agent.

  2. Schritt 2, Veröffentlichen von Buildartefakten, veröffentlicht das allgemeine Anwendungsimagepackage als Artefakt.

Übernehmen Sie diese Änderungen an Ihrer Hauptzweigung. Öffnen Sie in Azure DevOps Pipelines erneut. Es sollte eine Ausführung Der Pipeline ausgeführt oder gerade abgeschlossen werden. Wenn die Ausführung ein grünes Häkchen anzeigt, war der Build erfolgreich. Wählen Sie die erfolgreiche Ausführung aus; In der Spalte "Verwandtes" sollte "1 Veröffentlicht" angezeigt werden. Laden Sie dieses Artefakt herunter, und entpacken Sie die Imagepackage-Datei. Sie können dann eine Bereitstellung erstellen oder die Anwendung auf Ihr Gerät querladen.

Hinzufügen einer kontinuierlichen Integration zu Azure Sphere-Beispielanwendungen

GitHub-Aktionen und Azure-Pipelines sollen Builds für ein einzelnes Projekt automatisieren, z. B. solche, die aus dem Microsoft-Beispielbrowser heruntergeladen wurden. Die Azure Sphere Samples auf GitHub sind eine Sammlung von Projekten mit einigen freigegebenen Ressourcen. Um eines dieser Beispiele in der kontinuierlichen Integration zu verwenden, müssen Sie alle erforderlichen freigegebenen Ressourcen integrieren. In der Regel bedeutet dies, dass mindestens ein HardwareDefinitions-Verzeichnis im Verzeichnis der obersten Ebene Ihres Projekts erstellt und die CMakeLists.txt Datei bearbeitet wird, um auf die lokale Kopie zu verweisen. Wenn Sie beispielsweise ein Projekt basierend auf dem Beispiel "HelloWorld/HelloWorld_HighLevelApp" erstellen, sieht das Verzeichnis der obersten Ebene zunächst wie folgt aus:

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

Die datei CMakeLists.txt enthält die folgende Zeile, die auf das freigegebene HardwareDefinitions-Verzeichnis im Samples-Repository zeigt:

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

Um das Erstellen ihres Projekts zu ermöglichen, kopieren Sie den Ordner "HardwareDefinitions" in das Verzeichnis der obersten Ebene, und bearbeiten Sie dann die CMakeLists.txt Datei, um den lokalen Speicherort zu verwenden:

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

Überprüfen Sie erneut, ob Ihr Projekt lokal erstellt wird, bevor Sie versuchen, mit GitHub-Aktionen zu automatisieren.