CI/CD для C++ проектов: Настройка GitHub Actions

Онлайн-тренажер Python для начинающих

Изучайте Python легко и без перегрузки теорией. Решайте практические задачи с автоматической проверкой, получайте подсказки на русском языке и пишите код прямо в браузере — без необходимости что-либо устанавливать.

Начать курс

CI/CD для C++ проектов: Полное руководство по настройке GitHub Actions

В современной разработке программного обеспечения автоматизация процессов сборки, тестирования и развертывания стала не просто удобством, а необходимостью. Для C++ проектов, которые часто отличаются сложной системой сборки и зависимостями, внедрение CI/CD (Continuous Integration / Continuous Deployment) особенно актуально. В этой статье мы подробно разберем, как настроить пайплайн CI/CD для C++ проектов с использованием GitHub Actions — мощного и встроенного инструмента автоматизации.

Что такое GitHub Actions и почему он подходит для C++?

GitHub Actions — это платформа для автоматизации рабочих процессов (workflows), которая позволяет создавать пайплайны CI/CD прямо в вашем репозитории на GitHub. Для C++ разработчиков это идеальное решение по нескольким причинам:

  • Бесплатные минуты сборки для публичных репозиториев.
  • Поддержка Linux, macOS и Windows — вы можете тестировать кросс-платформенную сборку.
  • Гибкая конфигурация через YAML-файлы.
  • Огромная экосистема готовых действий (actions) для установки компиляторов, зависимостей и инструментов.

Основной элемент — это workflow, который описывается в файле .github/workflows/*.yml. Каждый workflow состоит из одного или нескольких jobs (задач), которые выполняются на виртуальных машинах (runner'ах).

Настройка базового пайплайна: сборка и тестирование

Начнем с самого простого — создадим workflow, который будет собирать ваш C++ проект с помощью CMake и запускать тесты каждый раз, когда вы отправляете изменения в ветку main или создаете Pull Request.

Создайте файл .github/workflows/build.yml в корне вашего репозитория и добавьте в него следующий код:

name: C++ CI Build

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Install dependencies
      run: |
        sudo apt-get update
        sudo apt-get install -y cmake g++ libgtest-dev

    - name: Configure CMake
      run: cmake -B build -DCMAKE_BUILD_TYPE=Release

    - name: Build
      run: cmake --build build --config Release

    - name: Run tests
      working-directory: ./build
      run: ctest --output-on-failure

Разберем этот код по шагам:

  • name — имя workflow, которое будет отображаться в интерфейсе GitHub.
  • on — триггеры, по которым запускается workflow (push и pull_request в main).
  • runs-on — операционная система runner'а (ubuntu-latest, windows-latest, macos-latest).
  • actions/checkout — стандартное действие, которое клонирует ваш репозиторий.
  • Install dependencies — устанавливаем CMake, компилятор GCC и библиотеку Google Test для юнит-тестов.
  • Configure, Build, Run tests — стандартные команды CMake для сборки и запуска тестов.

Оптимизация: кэширование и матричная сборка

Базовый пайплайн работает, но его можно значительно улучшить. Две ключевые техники — кэширование зависимостей и матричная сборка.

Кэширование для ускорения сборки

Каждый раз при запуске workflow runner скачивает все зависимости заново. Это занимает время. Используйте actions/cache, чтобы сохранять кэш CMake и установленных пакетов:

    - name: Cache CMake build
      uses: actions/cache@v3
      with:
        path: |
          build
          /usr/local/include
          /usr/local/lib
        key: ${{ runner.os }}-cmake-${{ hashFiles('**/CMakeLists.txt') }}
        restore-keys: |
          ${{ runner.os }}-cmake-

    - name: Install dependencies (если кэш не найден)
      run: |
        sudo apt-get update
        sudo apt-get install -y cmake g++ libgtest-dev
      if: steps.cache.outputs.cache-hit != 'true'

Ключ кэша (key) генерируется на основе хеша файлов CMakeLists.txt. Это гарантирует, что при изменении конфигурации сборки кэш будет сброшен.

Матричная сборка для нескольких платформ

Если вы разрабатываете кроссплатформенное приложение, вам нужно тестировать его на Windows, Linux и macOS. GitHub Actions поддерживает матрицу стратегий:

jobs:
  build:
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        compiler: [gcc, clang]
        exclude:
          - os: windows-latest
            compiler: clang  # На Windows используем MSVC
    runs-on: ${{ matrix.os }}

    steps:
    - name: Setup compiler
      run: |
        if [ "${{ matrix.compiler }}" == "gcc" ]; then
          echo "CC=gcc" >> $GITHUB_ENV
          echo "CXX=g++" >> $GITHUB_ENV
        else
          echo "CC=clang" >> $GITHUB_ENV
          echo "CXX=clang++" >> $GITHUB_ENV
        fi
      shell: bash

Теперь ваш пайплайн автоматически запустит 5 параллельных сборок (2 OS * 2 компилятора, минус исключенная комбинация). Это позволяет быстро выявить проблемы совместимости.

Непрерывная доставка: публикация артефактов и релизов

После успешной сборки и тестирования можно автоматизировать создание релиза и публикацию бинарных файлов. Для этого мы добавим job, который запускается только после успешного завершения сборки и только при пуше в main.

  deploy:
    needs: build
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest

    steps:
    - name: Checkout
      uses: actions/checkout@v4

    - name: Build Release
      run: |
        cmake -B build -DCMAKE_BUILD_TYPE=Release
        cmake --build build --config Release

    - name: Upload artifact
      uses: actions/upload-artifact@v3
      with:
        name: my-app-linux
        path: build/my_app

    -                

Блоги

Рекомендаций по книгам