Compartilhar via

Adicionar integração contínua às compilações de contêiner

  • Artigo

Importante

Esta é a documentação do Azure Sphere (herdado). O Azure Sphere (herdado) será desativado em 27 de setembro de 2027 e os usuários devem migrar para o Azure Sphere (integrado) até esse momento. Use o seletor de versão localizado acima do sumário para exibir a documentação do Azure Sphere (Integrado).

A integração contínua é um processo de desenvolvimento de software no qual um aplicativo é mantido em um estado continuamente liberável, fornecendo compilações automatizadas com cada confirmação em uma base de código específica. Você pode adicionar integração contínua a praticamente qualquer sistema de build, mas dois que são particularmente convenientes são GitHub Actions e Azure Pipelines. Neste tópico, você verá como usar o GitHub Actions ou o Azure Pipelines para automatizar as etapas de build do Docker descritas em Usar contêineres para criar aplicativos do Azure Sphere.

Usar GitHub Actions para criar automaticamente seu contêiner

O GitHub Actions permite que você automatize seu processo de compilação diretamente de seus repositórios GitHub. Portanto, a primeira etapa no uso do GitHub Actions é criar ou abrir um repositório GitHub que contenha o código do aplicativo. Este tópico pressupõe que você tenha criado um repositório GitHub contendo o aplicativo Blink gerado no Tutorial: Criar um aplicativo de alto nível e que seu projeto seja chamado de "Blink". Como em qualquer projeto de integração contínua, certifique-se de que seu projeto seja compilado localmente e forneça os artefatos esperados antes de tentar automatizar o processo. Neste exemplo, supomos que, após uma compilação bem-sucedida, o out diretório contenha um arquivo Blink.imagepackage.

No diretório de nível superior do repositório GitHub, crie um diretório chamado .devcontainer e crie um arquivo chamado Dockerfile nesse diretório com o seguinte conteúdo:

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

A linha inicial FROM especifica a imagem padrão do Docker do Azure Sphere como o contêiner de desenvolvimento base e a segunda diz para usar esse contêiner base como o ambiente de build. A COPY linha copia o conteúdo do repositório para o diretório /src/ do contêiner. O WORKDIR especifica o diretório de compilação. O RUN comando fornece o comando CMake para gerar os arquivos de compilação. Por fim, o especifica que ninja ENTRYPOINT deve ser invocado para realmente construir o aplicativo.

No diretório de nível superior do repositório, crie o diretório .github/workflows e adicione um arquivo chamado ci.yml com o seguinte conteúdo:

# 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

Esse fluxo de trabalho tem apenas um trabalho: criar o aplicativo; o trabalho é executado em um executor do GitHub Actions, neste casoubuntu-latest, e tem quatro etapas:

  1. A etapa 1, Checkout, é uma ação padrão do GitHub que simplesmente verifica seu repositório para o executor ubuntu-latest.

  2. A etapa 2 cria a imagem (docker build) e inicia o contêiner (docker run).

  3. A etapa 3 copia a saída do contêiner para o executor.

  4. A etapa 4, Publicar imagepackage HL, publica o imagepackage do aplicativo de alto nível como um artefato.

Confirme essas alterações em seu branch principal e selecione Ações. Agora você deve ver uma página rotulada "Todos os fluxos de trabalho", com pelo menos um fluxo de trabalho em execução ou concluído. Se o fluxo de trabalho for concluído com êxito, uma marca de seleção verde aparecerá ao lado dele. Clique em um fluxo de trabalho bem-sucedido e você verá uma caixa chamada "Artefatos" contendo um artefato chamado "HL imagepackage". Baixe esse artefato e descompacte o arquivo imagepackage; Em seguida, você pode criar uma implantação ou fazer sideload do aplicativo em seu dispositivo.

Usar o Azure Pipelines para criar automaticamente seu contêiner

O Azure Pipelines permite que você automatize seu processo de build diretamente de seus repositórios do GitHub (e muitos outros repositórios de código também). Este tópico pressupõe que você já pertença a uma organização com um projeto do Azure DevOps e tenha acesso ao Azure Pipelines. A primeira etapa no uso do Azure Pipelines é criar ou abrir um repositório que contenha o código do aplicativo. Este tópico pressupõe que você tenha criado um repositório GitHub contendo o aplicativo Blink gerado no Tutorial: Criar um aplicativo de alto nível.

No diretório de nível superior desse repositório, crie o diretório .devcontainer e crie um arquivo Dockerfile nesse diretório com o seguinte conteúdo:

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

A linha inicial FROM especifica a imagem padrão do Docker do Azure Sphere como o contêiner de desenvolvimento base e a segunda diz para usar esse contêiner base como o ambiente de build. A COPY linha copia o conteúdo do repositório para o diretório /src/ do contêiner. O WORKDIR especifica o diretório de compilação. O RUN comando fornece o comando CMake para gerar os arquivos de compilação. Por fim, o especifica que ninja ENTRYPOINT deve ser invocado para realmente construir o aplicativo.

Para criar o pipeline:

  1. Faça logon no projeto do Azure DevOps e abra o Pipelines.
  2. Selecione Novo Pipeline e, em seguida, selecione GitHub quando perguntado Onde está seu código? Você pode ser levado a uma página de autenticação do GitHub; Conclua a autenticação e vá para a página para selecionar seu repositório.
  3. Selecione seu repositório Blink. Você é levado para uma página intitulada Configurar seu pipeline.
  4. Selecione Pipeline de início. Isso abre um arquivo chamado azure-pipelines.yml no diretório de nível superior do repositório com uma tarefa Olá, Mundo.
  5. Selecione Salvar e executar. Aceite a mensagem de confirmação padrão e selecione novamente Salvar e executar. O arquivo azure-pipelines.yml é confirmado no repositório GitHub e o pipeline é criado.

Substitua o conteúdo do arquivo azure-pipelines.yml pelo seguinte conteúdo:

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

Esse fluxo de trabalho tem apenas um trabalho: criar o aplicativo; o trabalho é executado em um agente do Azure DevOps, neste casoubuntu-latest, e tem duas etapas:

  1. A etapa 1 cria a imagem (docker build), inicia o contêiner (docker run) e copia a saída do contêiner para o agente.

  2. A Etapa 2, Publicar artefatos de build, publica o imagepackage do aplicativo de alto nível como um artefato.

Confirme essas alterações em seu branch principal. No Azure DevOps, abra o Pipelines novamente. Você deve ver uma execução do pipeline em andamento ou recém-concluída. Se a execução mostrar uma marca de seleção verde, a compilação foi bem-sucedida. Selecione a execução bem-sucedida; você deve ver 1 Publicado na coluna Relacionado . Baixe este artefato e descompacte o arquivo imagepackage; Em seguida, você pode criar uma implantação ou fazer sideload do aplicativo em seu dispositivo.

Adicionar integração contínua a aplicativos de exemplo do Azure Sphere

O GitHub Actions e o Azure Pipelines destinam-se a automatizar builds para um único projeto, como os baixados do navegador de exemplos da Microsoft. Os exemplos do Azure Sphere no GitHub são uma coleção de projetos com alguns recursos compartilhados. Para usar um desses exemplos na integração contínua, você precisa incorporar todos os recursos compartilhados necessários. Normalmente, isso significa pelo menos criar um diretório HardwareDefinitions no diretório de nível superior do seu projeto e editar o arquivo CMakeLists.txt para apontar para a cópia local. Por exemplo, se você criar um projeto com base no exemplo HelloWorld/HelloWorld_HighLevelApp, o diretório de nível superior inicialmente terá esta aparência:

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

O arquivo CMakeLists.txt contém a seguinte linha apontando para o diretório HardwareDefinitions compartilhado no repositório Samples:

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

Para permitir que seu projeto seja compilado, copie a pasta HardwareDefinitions para o diretório de nível superior e edite o arquivo CMakeLists.txt para usar o local local:

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

Novamente, verifique se o projeto é compilado localmente antes de tentar automatizar com GitHub Actions.