# CMake with CI pipelines - Basics?

**URL:** https://discourse.cmake.org/t/cmake-with-ci-pipelines-basics/14313
**Category:** Usage
**Created:** [July 3, 2025, 3:54pm UTC](https://discourse.cmake.org/t/cmake-with-ci-pipelines-basics/14313 "2025-07-03T15:54:32Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![franki](https://discourse.cmake.org/letter_avatar_proxy/v4/letter/f/71c47a/32.png) [@franki](https://discourse.cmake.org/u/franki)
#### Post date: [July 3, 2025, 3:54pm UTC](https://discourse.cmake.org/t/cmake-with-ci-pipelines-basics/14313/1 "2025-07-03T15:54:32Z")

</div>

The simplest quick start is to add cmake -G and cmake --build to the build stage of the pipeline file, but this means that cmake’s generate/configure is redone every time! That’s wasteful especially if pulling in many dependencies that don’t change between incremental builds, e.g. via FetchContent.

I’m a rank beginner wanting to use GitLab CI, yet I suspect the basic principles apply to most/all CI systems. After hours of search, I can’t find good basic guidance for cmake with CI (as opposed to the minutia of one-offs).

Here is one post in our Community that starts to get at the core issues:

> [@Is is possible to cache the \_deps folder?](https://discourse.cmake.org/t/is-is-possible-to-cache-the-deps-folder/5276):
>
> Hi there, I’m setting up CI for a project. It takes a couple of minutes to generate the project and a lot of that time is spent downloading content using FetchContent. Since this content is unlikely to change regularly, it seems like it’s a good candidate to be cached. CircleCI makes caching easy with its save\_cache and restore\_cache commands. These commands take a key to identify the cache, which would typically be some kind of hash of some kind of lock file (e.g. key: npm-dependencies-{{ che…

So the basic CI pipeline elements would appear to be:  
“stages” - e.g. “build”, “test”, …  
“artifacts” - e.g. the resulting cmake -B build directory  
“caching” - e.g., (per above example post) saving the -B build directory artifact to reuse for the next incremental --build.  
“needs” - defining CI pipeline stage n-1 prerequisites to running stage n.

Are there any simple CI templates that employ cmake in effective/efficient manner? Any written guidance?

Thanks!

---

<div class="post-metadata">

### Author: ![ClausKlein](https://discourse.cmake.org/user_avatar/discourse.cmake.org/clausklein/32/352_2.png) [@ClausKlein](https://discourse.cmake.org/u/ClausKlein)
#### Post date: [July 3, 2025, 7:56pm UTC](https://discourse.cmake.org/t/cmake-with-ci-pipelines-basics/14313/2 "2025-07-03T19:56:28Z")

</div>

See: [starter-workflows/ci/cmake-single-platform.yml at main · actions/starter-workflows · GitHub](https://github.com/actions/starter-workflows/blob/main/ci/cmake-single-platform.yml)

GitHub has sample starter templates under actions menus, i.e.:

```yaml
# This starter workflow is for a CMake project running on multiple platforms. There is a different starter workflow if you just want a single platform.
# See: https://github.com/actions/starter-workflows/blob/main/ci/cmake-single-platform.yml
name: CMake on multiple platforms

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

jobs:
  build:
    runs-on: ${{ matrix.os }}

    strategy:
      # Set fail-fast to false to ensure that feedback is delivered for all matrix combinations. Consider changing this to true when your workflow is stable.
      fail-fast: false

      # Set up a matrix to run the following 3 configurations:
      # 1. <Windows, Release, latest MSVC compiler toolchain on the default runner image, default generator>
      # 2. <Linux, Release, latest GCC compiler toolchain on the default runner image, default generator>
      # 3. <Linux, Release, latest Clang compiler toolchain on the default runner image, default generator>
      #
      # To add more build types (Release, Debug, RelWithDebInfo, etc.) customize the build_type list.
      matrix:
        os: [ubuntu-latest, windows-latest]
        build_type: [Release]
        c_compiler: [gcc, clang, cl]
        include:
          - os: windows-latest
            c_compiler: cl
            cpp_compiler: cl
          - os: ubuntu-latest
            c_compiler: gcc
            cpp_compiler: g++
          - os: ubuntu-latest
            c_compiler: clang
            cpp_compiler: clang++
        exclude:
          - os: windows-latest
            c_compiler: gcc
          - os: windows-latest
            c_compiler: clang
          - os: ubuntu-latest
            c_compiler: cl

    steps:
    - uses: actions/checkout@v4

    - name: Set reusable strings
      # Turn repeated input strings (such as the build output directory) into step outputs. These step outputs can be used throughout the workflow file.
      id: strings
      shell: bash
      run: |
        echo "build-output-dir=${{ github.workspace }}/build" >> "$GITHUB_OUTPUT"

    - name: Configure CMake
      # Configure CMake in a 'build' subdirectory. `CMAKE_BUILD_TYPE` is only required if you are using a single-configuration generator such as make.
      # See https://cmake.org/cmake/help/latest/variable/CMAKE_BUILD_TYPE.html?highlight=cmake_build_type
      run: >
        cmake -B ${{ steps.strings.outputs.build-output-dir }}
        -DCMAKE_CXX_COMPILER=${{ matrix.cpp_compiler }}
        -DCMAKE_C_COMPILER=${{ matrix.c_compiler }}
        -DCMAKE_BUILD_TYPE=${{ matrix.build_type }}
        -S ${{ github.workspace }}

    - name: Build
      # Build your program with the given configuration. Note that --config is needed because the default Windows generator is a multi-config generator (Visual Studio generator).
      run: cmake --build ${{ steps.strings.outputs.build-output-dir }} --config ${{ matrix.build_type }}

    - name: Test
      working-directory: ${{ steps.strings.outputs.build-output-dir }}
      # Execute tests defined by the CMake configuration. Note that --build-config is needed because the default Windows generator is a multi-config generator (Visual Studio generator).
      # See https://cmake.org/cmake/help/latest/manual/ctest.1.html for more detail
      run: ctest --build-config ${{ matrix.build_type }}

```

An example with caching is found here: [cpp\_vcpkg\_project/.github/workflows/ci.yml at main · aminya/cpp\_vcpkg\_project · GitHub](https://github.com/aminya/cpp_vcpkg_project/blob/main/.github/workflows/ci.yml)