Aggiungere l'integrazione continua alle compilazioni del contenitoreAdd continuous integration to your container builds

L'integrazione continua è un processo di sviluppo del software in cui un'applicazione viene mantenuta in uno stato continuamente rilasciabile fornendo compilazioni automatiche con ogni commit a una base di codice specifica.Continuous integration is a software development process in which an application is kept in a continually releasable state by providing automated builds with each commit to a specific code base. È possibile aggiungere l'integrazione continua praticamente a qualsiasi sistema di compilazione, ma due sono particolarmente convenienti sono le azioni e Azure Pipelines di GitHub.You can add continuous integration to virtually any build system, but two that are particularly convenient are GitHub Actions and Azure Pipelines. In questo argomento si vedrà come usare le azioni di GitHub o Azure Pipelines per automatizzare i passaggi di compilazione di Docker descritti in usare i contenitori per compilare Azure Sphere app.In this topic, you will see how to use either GitHub Actions or Azure Pipelines to automate the Docker build steps described in Use containers to build Azure Sphere apps.

Usare le azioni di GitHub per compilare automaticamente il contenitoreUse GitHub Actions to automatically build your container

Le azioni di GitHub consentono di automatizzare il processo di compilazione direttamente dai repository GitHub.GitHub Actions allow you to automate your build process directly from your GitHub repositories. Quindi, il primo passaggio nell'uso delle azioni di GitHub consiste nel creare o aprire un repository GitHub contenente il codice dell'applicazione.Thus, the first step in using GitHub Actions is to create or open a GitHub repository that contains your application code. In questo argomento si presuppone che sia stato creato un repository GitHub contenente l'applicazione per il lampeggiamento generata nell'argomento esercitazione: creare un'applicazione di alto livello e che il progetto sia denominato "Blink".This topic assumes you have created a GitHub repository containing the Blink application generated in the topic Tutorial: Build a high-level application and that your project is named "Blink". Come per qualsiasi progetto di integrazione continua, verificare che il progetto venga compilato localmente e fornisca gli artefatti previsti prima di provare ad automatizzare il processo.As with any continuous integration project, make sure that your project builds locally and provides the expected artifacts before you attempt to automate the process. In questo esempio si presuppone che, dopo una compilazione riuscita, la out directory contenga un file Blink. imagepackage.In this example, we assume that after a successful build, the out directory contains a Blink.imagepackage file.

Nella directory di primo livello del repository GitHub creare una directory denominata. devcontainer e creare un file denominato Dockerfile in tale directory con il contenuto seguente:In the top-level directory of your GitHub repository, create a directory named .devcontainer, and create a file named Dockerfile in that directory with the following content:

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 FROM riga iniziale specifica l'immagine docker Azure Sphere standard come contenitore di sviluppo di base, mentre la seconda dice di usare tale contenitore di base come ambiente di compilazione.The initial FROM line specifies the standard Azure Sphere Docker image as the base development container, and the second says to use that base container as the build environment. La COPY riga copia il contenuto del repository nella directory/src/del contenitore.The COPY line copies the contents of the repository into the container's /src/ directory. WORKDIRSpecifica la directory di compilazione.The WORKDIR specifies the build directory. Il RUN comando fornisce il comando cmake per generare i file di compilazione.The RUN command provides the CMake command to generate the build files. Infine, ENTRYPOINT specifica che Ninja deve essere richiamato per compilare effettivamente l'applicazione.Finally, the ENTRYPOINT specifies that ninja should be invoked to actually build the application.

Nella directory di primo livello del repository creare la directory. github/workflows e aggiungere un file denominato ci. yml con il contenuto seguente:In the top-level directory of your repository, create the .github/workflows directory and add a file named ci.yml with the following content:

# 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/AzureSphereBlink.imagepackage

Questo flusso di lavoro ha un solo processo, per compilare l'applicazione. il processo viene eseguito in un Runner di azioni GitHub, in questo caso ubuntu-latest , ed è costituito da tre passaggi.This workflow has only one job—to build the application; the job runs on a GitHub Actions runner, in this case ubuntu-latest, and has three steps. Sono disponibili anche i runner Windows e Mac, ma ubuntu-latest è preferibile per le applicazioni Azure Sphere. Il primo passaggio, Checkout , è un'azione standard di GitHub che estrae semplicemente il repository al Runner Ubuntu-latest.(There are Windows and Mac runners as well, but ubuntu-latest is preferable for Azure Sphere applications.) The first step, Checkout, is a standard GitHub action that simply checks out your repository to the ubuntu-latest runner. Il secondo passaggio compila l'immagine ( docker build ) e avvia il contenitore ( docker run ).The second step builds the image (docker build) and starts the container (docker run). Il terzo passaggio copia l'output dal contenitore al Runner.The third step copies the output from the container to the runner. Il passaggio finale, Publish HL imagepackage, pubblica l'applicazione di alto livello imagepackage come artefatto.The final step, Publish HL imagepackage, publishes the high-level application imagepackage as an artifact.

Eseguire il commit di queste modifiche nel branch principale e selezionare azioni.Commit these changes to your main branch and select Actions. A questo punto dovrebbe essere visualizzata una pagina denominata "tutti i flussi di lavoro", con almeno un flusso di lavoro in esecuzione o completato.You should now see a page labeled "All workflows", with at least one workflow running or completed. Se il flusso di lavoro viene completato correttamente, accanto a un segno di spunta verde.If the workflow completes successfully, a green check mark appears beside it. Fare clic su un flusso di lavoro riuscito. verrà visualizzata una casella con etichetta "artefatti" contenente un artefatto con etichetta "HL imagepackage".Click on a successful workflow and you should see a box labeled "Artifacts" containing one artifact labeled "HL imagepackage". Scaricare questo artefatto e decomprimere il file imagepackage; è quindi possibile creare una distribuzione o sideload l'applicazione al dispositivo.Download this artifact and unpack the imagepackage file; you can then create a deployment or sideload the application to your device.

Usare Azure Pipelines per compilare automaticamente il contenitoreUse Azure Pipelines to automatically build your container

Azure Pipelines consentono di automatizzare il processo di compilazione direttamente dai repository GitHub (e anche da molti altri repository di codice).Azure Pipelines allow you to automate your build process directly from your GitHub repositories (and many other code repositories as well). Questo argomento presuppone che l'utente appartenga già a un'organizzazione con un progetto DevOps di Azure e abbia accesso ai Azure Pipelines.This topic assumes you already belong to an organization with an Azure DevOps project and have access to Azure Pipelines. Il primo passaggio nell'uso di Azure Pipelines consiste nel creare o aprire un repository che contiene il codice dell'applicazione.The first step in using Azure Pipelines is to create or open a repository that contains your application code. In questo argomento si presuppone che sia stato creato un repository GitHub contenente l'applicazione per il lampeggiamento generata nell'argomento esercitazione: creare un'applicazione di alto livello.This topic assumes you have created a GitHub repository containing the Blink application generated in the topic Tutorial: Build a high-level application.

Nella directory di primo livello di questo repository creare la directory. devcontainer e creare un file Dockerfile in tale directory con il contenuto seguente:In the top-level directory of this repository, create the .devcontainer directory, and create a Dockerfile file in that directory with the following content:

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 FROM riga iniziale specifica l'immagine docker Azure Sphere standard come contenitore di sviluppo di base, mentre la seconda dice di usare tale contenitore di base come ambiente di compilazione.The initial FROM line specifies the standard Azure Sphere Docker image as the base development container, and the second says to use that base container as the build environment. La COPY riga copia il contenuto del repository nella directory/src/del contenitore.The COPY line copies the contents of the repository into the container's /src/ directory. WORKDIRSpecifica la directory di compilazione.The WORKDIR specifies the build directory. Il RUN comando fornisce il comando cmake per generare i file di compilazione.The RUN command provides the CMake command to generate the build files. Infine, ENTRYPOINT specifica che Ninja deve essere richiamato per compilare effettivamente l'applicazione.Finally, the ENTRYPOINT specifies that ninja should be invoked to actually build the application.

Per creare la pipelineTo create the pipeline:

  1. Accedere al progetto Azure DevOps e aprire pipeline.Log in to your Azure DevOps project and open Pipelines.
  2. Selezionare nuova pipeline, quindi fare clic su GitHub quando viene chiesto dove si trova il codice?Select New Pipeline, then select GitHub when asked Where is your code? È possibile che venga eseguita una pagina di autenticazione di GitHub. completare l'autenticazione e passare alla pagina per selezionare il repository.You may be taken to a GitHub authentication page; complete the authentication and continue to the page to select your repository.
  3. Selezionare il repository di lampeggio.Select your Blink repository. Si viene indirizzati a una pagina intitolata Configurare la pipeline.You are taken to a page titled Configure your pipeline.
  4. Selezionare pipeline Starter.Select Starter pipeline. Viene aperto un file denominato Azure-Pipelines. yml nella directory di livello superiore del repository con un'attività Hello, World.This opens a file named azure-pipelines.yml in the top-level directory of your repository with a Hello, World task.
  5. Selezionare Salva ed esegui.Select Save and run. Accettare il messaggio di commit predefinito e selezionare di nuovo Salva ed Esegui.Accept the default commit message and again select Save and run. Il file Azure-Pipelines. yml viene sottoposta a commit nel repository GitHub e la pipeline viene creata.The azure-pipelines.yml file is committed to your GitHub repository and the pipeline is created.

Sostituire il contenuto del file Azure-Pipelines. yml con il contenuto seguente:Replace the contents of the azure-pipelines.yml file with the following content:

# Docker
# Build a Docker image
# https://docs.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/BlinkSample.imagepackage'
        ArtifactName: 'BlinkSample.imagepackage'
        publishLocation: 'Container'

Questo flusso di lavoro ha un solo processo, per compilare l'applicazione. il processo viene eseguito in un agente DevOps di Azure, in questo caso ubuntu-latest , ed è costituito da due passaggi.This workflow has only one job—to build the application; the job runs on a Azure DevOps agent, in this case ubuntu-latest, and has two steps. Sono disponibili anche gli agenti Windows e Mac, ma ubuntu-latest è preferibile per le applicazioni Azure Sphere. Il primo passaggio compila l'immagine ( docker build ), avvia il contenitore ( docker run ) e copia l'output dal contenitore all'agente.(There are Windows and Mac agents as well, but ubuntu-latest is preferable for Azure Sphere applications.) The first step builds the image (docker build), starts the container (docker run), and copies the output from the container to the agent. Il passaggio finale, Publish Build artefatts, pubblica il imagepackage dell'applicazione di alto livello come artefatto.The final step, Publish build artifacts, publishes the high-level application imagepackage as an artifact.

Eseguire il commit di queste modifiche nel branch principale.Commit these changes to your main branch. In Azure DevOps aprire di nuovo pipeline.In Azure DevOps, open Pipelines again. Verrà visualizzata un'esecuzione della pipeline in corso o appena completata.You should see a run of your pipeline in progress or just completed. Se l'esecuzione Mostra un segno di spunta verde, la compilazione ha avuto esito positivo.If the run shows a green checkmark, the build was successful. Selezionare l'esecuzione riuscita. verrà visualizzato 1 nella colonna correlata.Select the successful run; you should see 1 Published in the Related column. Scaricare questo artefatto e decomprimere il file imagepackage; è quindi possibile creare una distribuzione o sideload l'applicazione al dispositivo.Download this artifact and unpack the imagepackage file; you can then create a deployment or sideload the application to your device.

Aggiungere l'integrazione continua a Azure Sphere applicazioni di esempioAdd continuous integration to Azure Sphere sample applications

Le azioni e i Azure Pipelines di GitHub sono progettati per automatizzare le compilazioni per un singolo progetto.GitHub Actions and Azure Pipelines are meant to automate builds for a single project. Gli esempi di Azure Sphere sono una raccolta di progetti con alcune risorse condivise.The Azure Sphere Samples are a collection of projects with some shared resources. Per usare uno di questi esempi nell'integrazione continua, è necessario incorporare le risorse condivise necessarie.To use one of these samples in continuous integration, you need to incorporate any needed shared resources. In genere, ciò significa almeno creare una directory HardwareDefinitions nella directory di primo livello del progetto e modificare il file di CMakeLists.txt in modo che punti alla copia locale.Usually, this means at least creating a HardwareDefinitions directory in the top-level directory of your project and editing the CMakeLists.txt file to point to the local copy. Se, ad esempio, si crea un progetto basato sull'esempio HelloWorld/HelloWorld_HighLevelApp, la directory di primo livello sarà inizialmente simile alla seguente:For example, if you create a project based on the HelloWorld/HelloWorld_HighLevelApp sample, the top-level directory initially looks like this:

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

Il file di CMakeLists.txt contiene la riga seguente che punta alla directory HardwareDefinitions condivisa nel repository degli esempi:The CMakeLists.txt file contains the following line pointing to the shared HardwareDefinitions directory in the Samples repo:

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

Per abilitare la compilazione del progetto, copiare la cartella HardwareDefinitions nella directory di livello superiore, quindi modificare il file di CMakeLists.txt per usare il percorso locale:To enable your project to build, copy the HardwareDefinitions folder into your top-level directory, then edit the CMakeLists.txt file to use the local location:

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

Verificare di nuovo che il progetto venga compilato localmente prima di provare ad automatizzare le azioni di GitHub.Again, verify that your project builds locally before you attempt to automate with GitHub Actions.