Freigeben über

Hinzufügen von Continuous Integration zu Ihren Containerbuilds

  • Artikel

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

Verwenden von GitHub Actions zum automatischen Erstellen Ihres Containers

mit GitHub Actions können Sie Ihren Buildprozess direkt aus Ihren GitHub-Repositorys automatisieren. Daher besteht der erste Schritt bei der Verwendung von GitHub Actions 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 Tutorial: Erstellen einer allgemeinen Anwendung generiert wurde, und dass Ihr Projekt den Namen "Blink" trägt. Stellen Sie wie bei jedem Continuous Integration-Projekt 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 mit dem Namen Dockerfile in diesem Verzeichnis mit folgendem 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 Azure Sphere-Standard-Docker-Image als Basisentwicklungscontainer an, und die zweite besagt, dass dieser Basiscontainer als Buildumgebung verwendet werden soll. Die COPY Zeile kopiert den Inhalt des Repositorys in das Verzeichnis /src/ des Containers. Gibt WORKDIR das Buildverzeichnis an. Der RUN Befehl stellt den CMake-Befehl bereit, um die Builddateien zu generieren. Schließlich gibt an ENTRYPOINT , 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 namens ci.yml mit folgendem 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 az sphere 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 umfasst nur einen Auftrag, nämlich die Anwendung zu erstellen. Der Auftrag wird auf einem GitHub Actions-Runner ausgeführt, in diesem Fall ubuntu-latest, und umfasst vier Schritte:

  1. Schritt 1, Checkout, ist eine Standardmäßige GitHub-Aktion, die einfach Ihr Repository in den ubuntu-latest-Runner auscheckt.

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

  3. In Schritt 3 wird die Ausgabe aus dem Container in den Runner kopiert.

  4. Schritt 4, Hl-Imagepaket veröffentlichen, veröffentlicht das allgemeine Anwendungsimagepaket als Artefakt.

Committen Sie diese Änderungen in Ihren Standard Branch, und wählen Sie Aktionen aus. Nun sollte eine Seite mit der Bezeichnung "Alle Workflows" angezeigt werden, auf der mindestens ein Workflow ausgeführt oder abgeschlossen ist. Wenn der Workflow erfolgreich abgeschlossen wurde, wird daneben ein grünes Häkchen angezeigt. Klicken Sie auf einen erfolgreichen Workflow. Dann sollte ein Feld mit der Bezeichnung "Artifacts" (Artefakte) angezeigt werden, das ein Artefakt mit der Bezeichnung "HL imagepackage" enthält. Laden Sie dieses Artefakt herunter, und entpacken Sie die Imagepaketdatei. 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 organization 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 Tutorial: Erstellen einer allgemeinen Anwendung generiert wurde.

Erstellen Sie im Verzeichnis auf oberster Ebene dieses Repositorys das Verzeichnis .devcontainer, und erstellen Sie eine Dockerfile-Datei in diesem Verzeichnis mit folgendem 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 Azure Sphere-Standard-Docker-Image als Basisentwicklungscontainer an, und die zweite besagt, dass dieser Basiscontainer als Buildumgebung verwendet werden soll. Die COPY Zeile kopiert den Inhalt des Repositorys in das Verzeichnis /src/ des Containers. Gibt WORKDIR das Buildverzeichnis an. Der RUN Befehl stellt den CMake-Befehl bereit, um die Builddateien zu generieren. Schließlich gibt an ENTRYPOINT , dass Ninja aufgerufen werden soll, um die Anwendung tatsächlich zu erstellen.

So erstellen Sie die 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 ist Ihr Code? Sie können zu einer GitHub-Authentifizierungsseite weitergeleitet werden. 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 gelangen zu einer Seite mit dem Titel Konfigurieren Ihrer Pipeline.
  4. Wählen Sie Starterpipeline aus. Dadurch wird eine Datei namens azure-pipelines.yml im Verzeichnis der obersten Ebene Ihres Repositorys mit der Aufgabe Hello, World geöffnet.
  5. Wählen Sie Speichern und ausführen aus. Akzeptieren Sie die Standardcommitmeldung, und wählen Sie erneut Speichern und ausführen aus. Die Datei azure-pipelines.yml wird in Ihr GitHub-Repository committet, und die Pipeline wird erstellt.

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

# Docker
# Build a Docker image
# /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 umfasst nur einen Auftrag, nämlich die Anwendung zu erstellen. Der Auftrag wird auf einem Azure DevOps-Agent ausgeführt( in diesem Fall ubuntu-latest), und umfasst 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 Anwendungsimagepaket als Artefakt.

Committen Sie diese Änderungen in Ihren Standard-Branch. Öffnen Sie pipelines in Azure DevOps erneut. Sie sollten sehen, dass eine Ausführung Ihrer Pipeline ausgeführt wird oder gerade abgeschlossen ist. Wenn bei der Ausführung ein grünes Häkchen angezeigt wird, war der Build erfolgreich. Wählen Sie die erfolgreiche Ausführung aus. in der Spalte Verwandter Sollte 1 Veröffentlicht angezeigt werden. Laden Sie dieses Artefakt herunter, und entpacken Sie die Imagepaketdatei. Sie können dann eine Bereitstellung erstellen oder die Anwendung auf Ihr Gerät querladen.

Hinzufügen von Continuous Integration zu Azure Sphere-Beispielanwendungen

GitHub Actions und Azure Pipelines sollen Builds für ein einzelnes Projekt automatisieren, z. B. solche, die aus dem Microsoft-Beispielbrowser heruntergeladen wurden. Die Azure Sphere-Beispiele auf GitHub sind eine Sammlung von Projekten mit einigen freigegebenen Ressourcen. Um eines dieser Beispiele in Continuous Integration verwenden zu können, müssen Sie alle erforderlichen freigegebenen Ressourcen integrieren. In der Regel bedeutet dies, dass sie mindestens ein HardwareDefinitions-Verzeichnis im Verzeichnis der obersten Ebene Ihres Projekts erstellen und die CMakeLists.txt Datei so bearbeiten, dass sie auf die lokale Kopie verweist. Wenn Sie beispielsweise ein Projekt erstellen, das auf dem Beispiel HelloWorld/HelloWorld_HighLevelApp basiert, 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 CMakeLists.txt-Datei enthält die folgende Zeile, die auf das freigegebene Verzeichnis HardwareDefinitions im Beispielrepository verweist:

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 Ihr 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 Actions zu automatisieren.