Поделиться через

Добавление непрерывной интеграции в сборки контейнеров

  • Статья

Внимание

Это документация по Azure Sphere (устаревшая версия). Служба Azure Sphere (устаревшая версия) выходит на пенсию 27 сентября 2027 г., и к этому времени пользователи должны перейти в Azure Sphere (интегрированная). Используйте селектор версий, расположенный над toC, чтобы просмотреть документацию по Azure Sphere (интегрированная).

Непрерывная интеграция — это процесс разработки программного обеспечения, в котором приложение хранится в постоянно освобождаемом состоянии, предоставляя автоматические сборки с каждой фиксацией в определенной базе кода. Вы можете добавить непрерывную интеграцию в практически любую систему сборки, но два из них особенно удобны: GitHub Actions и Azure Pipelines. В этом разделе вы узнаете, как использовать GitHub Actions или Azure Pipelines для автоматизации шагов сборки Docker, описанных в разделе "Использование контейнеров для создания приложений Azure Sphere".

Использование GitHub Actions для автоматической сборки контейнера

GitHub Actions позволяет автоматизировать процесс сборки непосредственно из репозиториев GitHub. Таким образом, первым шагом в использовании GitHub Actions является создание или открытие репозитория GitHub, содержащего код приложения. В этом разделе предполагается, что вы создали репозиторий GitHub, содержащий приложение Blink, созданное в руководстве: создание высокоуровневого приложения , и что проект называется "Blink". Как и в случае с любым проектом непрерывной интеграции, убедитесь, что проект выполняет сборку локально и предоставляет ожидаемые артефакты перед попыткой автоматизировать процесс. В этом примере предполагается, что после успешной сборки out каталог содержит файл Blink.imagepackage.

В каталоге верхнего уровня репозитория GitHub создайте каталог с именем devcontainer и создайте файл с именем Dockerfile в этом каталоге со следующим содержимым:

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

FROM Начальная строка указывает стандартный образ Docker Azure Sphere в качестве базового контейнера разработки, а второй — использовать этот базовый контейнер в качестве среды сборки. Строка COPY копирует содержимое репозитория в каталог контейнера /src/. Указывает WORKDIR каталог сборки. Эта RUN команда предоставляет команду CMake для создания файлов сборки. Наконец, указывает ENTRYPOINT , что ninja следует вызвать для фактической сборки приложения.

В каталоге верхнего уровня репозитория создайте каталог github/workflows и добавьте файл с именем ci.yml со следующим содержимым:

# 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

Этот рабочий процесс имеет только одно задание— для создания приложения; Задание выполняется в GitHub Actions runner, в данном случае ubuntu-latestи имеет четыре шага:

  1. Шаг 1. CheckoutЭто стандартное действие GitHub, которое просто проверяет репозиторий в ubuntu-latest runner.

  2. Шаг 2 создает образ (docker build) и запускает контейнер (docker run).

  3. Шаг 3 копирует выходные данные из контейнера в средство выполнения.

  4. Шаг 4. Публикация образа HL, публикация высокоуровневого образа приложения в качестве артефакта.

Зафиксируйте эти изменения в главной ветви и выберите "Действия". Теперь вы увидите страницу со значением "Все рабочие процессы" с по крайней мере одним рабочим процессом, запущенным или завершенным. Если рабочий процесс завершится успешно, рядом с ним появится зеленая галочка. Щелкните успешный рабочий процесс, и вы увидите поле с меткой "Артефакты", содержащей один артефакт с меткой "HL imagepackage". Скачайте этот артефакт и распакуйте файл imagepackage; Затем можно создать развертывание или загрузить неопубликованное приложение на устройство.

Использование Azure Pipelines для автоматической сборки контейнера

Azure Pipelines позволяет автоматизировать процесс сборки непосредственно из репозиториев GitHub (и многих других репозиториев кода). В этом разделе предполагается, что вы уже принадлежите организации с проектом Azure DevOps и имеете доступ к Azure Pipelines. Первым шагом в использовании Azure Pipelines является создание или открытие репозитория, содержащего код приложения. В этом разделе предполагается, что вы создали репозиторий GitHub, содержащий приложение Blink, созданное в руководстве: создание высокоуровневого приложения.

В каталоге верхнего уровня этого репозитория создайте каталог devcontainer и создайте файл Dockerfile в этом каталоге со следующим содержимым:

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

FROM Начальная строка указывает стандартный образ Docker Azure Sphere в качестве базового контейнера разработки, а второй — использовать этот базовый контейнер в качестве среды сборки. Строка COPY копирует содержимое репозитория в каталог контейнера /src/. Указывает WORKDIR каталог сборки. Эта RUN команда предоставляет команду CMake для создания файлов сборки. Наконец, указывает ENTRYPOINT , что ninja следует вызвать для фактической сборки приложения.

Чтобы создать конвейер

  1. Войдите в проект Azure DevOps и откройте Pipelines.
  2. Выберите новый конвейер, а затем выберите GitHub , когда его спросили , где находится ваш код? Вы можете отправиться на страницу проверки подлинности GitHub; завершите проверку подлинности и перейдите на страницу, чтобы выбрать репозиторий.
  3. Выберите репозиторий Blink. Вы перейдете на страницу с заголовком "Настройка конвейера".
  4. Выберите Простейший конвейер. Откроется файл с именем azure-pipelines.yml в каталоге верхнего уровня репозитория с задачей Hello, World.
  5. Выберите Сохранить и выполнить. Примите сообщение фиксации по умолчанию и снова нажмите кнопку "Сохранить и запустить". Файл azure-pipelines.yml фиксируется в репозитории GitHub и создается конвейер.

Замените содержимое файла azure-pipelines.yml следующим содержимым:

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

Этот рабочий процесс имеет только одно задание— для создания приложения; Задание выполняется в агенте Azure DevOps, в данном случае ubuntu-latestи имеет два шага:

  1. Шаг 1 создает образ (docker build), запускает контейнер (docker run) и копирует выходные данные из контейнера в агент.

  2. Шаг 2. Публикация артефактов сборки публикует высокоуровневый образ приложения в качестве артефакта.

Зафиксируйте эти изменения в главной ветви. В Azure DevOps снова откройте конвейеры . Вы должны увидеть выполнение конвейера или только что завершено. Если в ходе выполнения отображается зеленая галочка, сборка выполнена успешно. Выберите успешный запуск; Вы увидите 1 опубликовано в связанном столбце. Скачайте этот артефакт и распакуйте файл imagepackage; Затем можно создать развертывание или загрузить неопубликованное приложение на устройство.

Добавление непрерывной интеграции в примеры приложений Azure Sphere

GitHub Actions и Azure Pipelines предназначены для автоматизации сборок для одного проекта, например скачанных из браузера примеров Майкрософт. Примеры Azure Sphere на GitHub — это коллекция проектов с некоторыми общими ресурсами. Чтобы использовать один из этих примеров в непрерывной интеграции, необходимо включить все необходимые общие ресурсы. Обычно это означает по крайней мере создание каталога HardwareDefinitions в каталоге верхнего уровня проекта и редактирование файла CMakeLists.txt, чтобы указать локальную копию. Например, если вы создаете проект на основе примера HelloWorld/HelloWorld_HighLevelApp, каталог верхнего уровня изначально выглядит следующим образом:

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

Файл CMakeLists.txt содержит следующую строку, указывающую на общий каталог HardwareDefinitions в репозитории Samples:

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

Чтобы включить сборку проекта, скопируйте папку HardwareDefinitions в каталог верхнего уровня, а затем измените файл CMakeLists.txt, чтобы использовать локальное расположение:

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

Еще раз убедитесь, что проект выполняет сборку локально, прежде чем пытаться автоматизировать работу с помощью GitHub Actions.