C++ Matrix

Testing C libraries can be a challenging and time-consuming task, especially when considering the various compiler versions, error behaviors, and platform dependencies. A library that works flawlessly with one compiler might encounter issues when compiled with a different version or on a different platform. This is where the C Library Test Matrix GitHub Action comes to the rescue.

The C Library Test Matrix GitHub Action is designed to automate the generation of a comprehensive test matrix for your C libraries given their requirements. It simplifies the process of testing your libraries across multiple compiler versions and platforms, reducing the manual effort and potential for human error.

With this action, you can define a set of compiler versions, target platforms, standard requirements, and factors that you want to test your C++ library against. The action then automatically generates a test matrix by combining the specified compilers and platforms into a fractional factorial design, enabling you to run tests in a systematic and efficient manner.

This action can ensure that your C++ library is thoroughly tested across a wide range of compiler versions and platforms. This approach significantly increases the chances of catching compatibility issues early on and helps in delivering a robust and reliable library that works across different environments.

  • Automated test matrix generation: Define a list of compiler versions and platforms, and let the action handle the creation of the test matrix.

  • Easy integration: Simply include the C++ Library Test Matrix GitHub Action in your workflow configuration to start generating the test matrix.

  • Customization options: Fine-tune the test matrix generation process by specifying additional compiler flags, build configurations, or test suites.

  • Comprehensive test coverage: Ensure your C++ library is thoroughly tested across multiple compiler versions and platforms to identify and address compatibility issues.

Get started with the C Library Test Matrix GitHub Action today and streamline your C library testing process. Say goodbye to manual matrix creation and embrace automated, systematic testing to deliver high-quality C++ libraries that work seamlessly across different compilers and platforms.

Usage

The action should be run as extra initial “setup” job in your workflow. The job will run the action and output matrix, which is a JSON string containing the whole matrix. This matrix should be output of your first setup job.

In your second build job, you can attribute the entire matrix to the strategy.matrix.include parameter and create your workflow as usual with the parameters from the matrix:

jobs:
  cpp-matrix:
    runs-on: ubuntu-latest
    name: Generate Test Matrix
    outputs:
      matrix: ${{ steps.cpp-matrix.outputs.matrix }}
    steps:
      - name: Generate Test Matrix
        uses: alandefreitas/cpp-actions/cpp-matrix@v1.4.0
        id: cpp-matrix
        with:
          standards: '>=11'
  build:
    needs: cpp-matrix
    strategy:
      fail-fast: false
      matrix:
        include: fromJSON(needs.cpp-matrix.outputs.matrix)

    # use matrix entries
    name: ${{ matrix.name }}
    runs-on: ${{ matrix.runs-on }}
    container: ${{ matrix.container }}

    steps:
      - name: Clone library
        uses: actions/checkout@v3

      - name: Setup C++ Compiler
        uses: alandefreitas/cpp-actions/setup-cpp@v1.4.0
        id: setup-cpp
        with:
          compiler: ${{ matrix.compiler }}
          version: ${{ matrix.version }}

      - name: CMake Workflow
        uses: ./cmake-workflow
        with:
          cc: ${{ steps.setup-cpp.outputs.cc || matrix.cc }}
          cxx: ${{ steps.setup-cpp.outputs.cxx || matrix.cxx }}
          cxxstd: ${{ matrix.cxxstd }}
          cxxflags: ${{ matrix.cxxstd }}

      # And you've safely tested your C++ library just like that...

Example

steps:
- name: Generate Test Matrix
  uses: alandefreitas/cpp-actions/cpp-matrix@v1.4.0
  id: cpp-matrix
  with:
    standards: '>=11'
    factors: 'gcc Asan Shared No-Deps

      msvc Shared x86

      clang Time-Trace

      mingw Shared

      '

Input Parameters

Parameter

Description

Default

compilers

A list of compilers to be tested. Each compiler can be complemented with its semver version requirements to be tested.

When the compiler version requirements are provided, the action will break the requirements into subsets of major versions to be tested. When no version is provided, the '*' semver requirement is assumed. The action can identifies subsets of compiler versions for GCC, Clang, and MSVC. For any other compilers, the version requirements will passthrough to the output. .

gcc >=4.8

clang >=3.8

msvc >=14.2

apple-clang *

mingw *

clang-cl *

standards

A semver range describing what C standards should be tested.

The compiler ranges are adjusted to only include compilers that support any subrange of these requirements.

These requirements can include C standards as 2 or 4 digits versions, such as 11, 2011, 98, or 1998. 2 digit versions are normalized into the 4 digits form so that 11 > 98 (2011 > 1998). .

>=11

max-standards

The maximum number of standards to be tested with each compiler.

For instance, if 'max-standards' is 2 and the compiler supports '11,14,17,20,23' given the in the standard requirements, the standards 20,23 will be tested by this compiler. .

2

latest-factors

The factors to be tested with the latest versions of each compiler. For each factor in this list, the entry with the latest version of a compiler will be duplicated with an entry that sets this factor to true.

Other entries will also include this factor as false.

The following factors are considered special: 'asan', 'ubsan', 'msan', 'tsan', and 'coverage'. When these factors are defined in an entry, its 'ccflags', 'cxxflags', and 'linkflags' value are also modified to include the suggested flags for factor. .

gcc Coverage TSan UBSan

factors

The factors to be tested with other versions of each compiler. Each factor in this list will be injected into a version of the compiler that is not the latest version. An entry with the latest version of the compiler will be duplicated with this factor if there are no entries left to inject the factor.

Other entries will also include this factor as false. .

gcc Asan Shared

msvc Shared x86

clang Time-Trace

mingw Shared

generate-summary

Generate summary with the complete matrix.

true

trace-commands

Trace commands executed by the action.

false

Outputs

Output

Description

matrix

The test matrix is an array of dictionaries, where each entry represents a combination of compiler version and factors to be tested.

Each entry in the test matrix dictionary contains the following key-value pairs:

- name: A suggested name for the job testing this entry

- runs-on: A suggested github runner image name for the job testing this entry

- container: A suggested docker container for the job testing this entry

- compiler: Specifies the name of the compiler to be used for the test configuration. This can be used as input to the setup-cpp action.

- version: Specifies the version requirements of the compiler to be used for the test configuration. This can be used as input to the setup-cpp action.

- is-latest: Specifies whether the entry version requirement is the latest version among the test configurations.

- is-main: Specifies whether the entry version requirement is the latest version among the test configurations without any factors applied.

- is-earliest: Specifies whether the entry version requirement is the earliest version among the test configurations.

- cxx: The usual name of the C compiler executable. If using the `setup-cpp` action, its output should be used instead.

- `cc`: The usual name of the C compiler executable. If using the `setup-cpp` action, its output should be used instead.

- `cxxstd`: A list of standards that should be tested with this compiler version. This option considers the `max-standards` latest standards supported by each compiler in its subrange of `standards`.

- `b2-toolset`: The usual name of the toolset to be used in a b2 workflow.

- `generator`: A CMake generator recommended to run the CMake workflow.

- `build-type`: A build type recommended to test this entry. This is usually `Release`, unless some special factor that requires `Debug` is defined.

- `ccflags`: The recommended C flags to be used by this entry. It reflects the values of special factors, such as sanitizers, coverage, and time-trace.

- `cxxflags`: The recommended C flags to be used by this entry. It reflects the values of special factors, such as sanitizers, coverage, and time-trace.

- install: The recommended packages to be installed before running the workflow. This includes packages such as build-essential for ubuntu containers and lcov for coverage entries.

- <factors>…​: Provides additional factors or attributes associated with the test configuration as defined by the factors and latest-factors inputs. These usually include variant build configurations spread among the entries, such as asan, coverage, and shared libraries.