Mastering Github Actions - Part 2

Testing microservices or applications with CI/CD pipelines becomes complex when you need to test different operating systems like Linux, Windows, and macOS. Not just that—you might also need to test across different OS architectures like x86 or ARM and such. Or perhaps you want to ensure that your application works with all versions of Python 3.x and above.

At first glance, testing across all these combinations seems like it would be chaotic with GitHub Actions.

These kinds of use cases have one thing in common: different parameters. The solution is to create one job that is compatible with these parameters, and then run it in parallel across all the different configurations.

Well, not really—thanks to the matrix strategy, it's actually quite manageable.

My Experience with Github Matrix

As we know, GitHub Actions jobs are designed to run in parallel by default, and within each job, steps execute sequentially. that means if you don't use the needs keyword in jobs and you have two jobs, they will start at the same time.

In our project, we had implemented sequential GitHub Actions jobs using the needs feature. Our workflow was structured like this: Job 1 ==> Job 2 ==> Job 3. Each job would wait for the previous one to complete before starting.

Later, in our project, we received a new requirement. Our use case required running this sequence of jobs for three different machines. However, the way we had implemented it was not efficient. For these three different machines, we created three separate workflows—three separate YAML files. The only difference between them was the input parameters for each machine. Everything else was identical.

This approach bothered me. I thought, "Why can't I optimize this? Why am I not following the DRY (Don't Repeat Yourself) principle? Why do I need three YAML files for essentially the same thing?"

We resolved our above requirement and made it more efficient using the matrix strategy.

Using the matrix strategy, a single job can create multiple jobs with different parameters, and all of them will run in parallel.

Main Course

GitHub Actions matrix is a strategy that lets you run the same job multiple times with different configurations in parallel. It's incredibly useful for testing across multiple environments without duplicating your workflow code.

simple example from github documentation.

jobs:
  example_matrix:
    strategy:
      matrix:
        version: [10, 12, 14]
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.version }}

This creates 3 parallel jobs, one for each Node.js version.

Multi-Dimensional Matrix

You can combine multiple variables:

jobs:
  example_matrix:
    strategy:
      matrix:
        os: [ubuntu-22.04, ubuntu-20.04]
        version: [10, 12, 14]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.version }}

This creates 6 jobs (2 OS × 3 Node versions).

Include Exclude Feature

Include/Exclude: Add specific combinations or exclude certain ones:

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
    node-version: [16, 18]
    exclude:
      - os: windows-latest
        node-version: 16
    include:
      - os: macos-latest
        node-version: 18

Matrix strategies help you efficiently test across multiple environments, versions, or configurations without repeating workflow code.

Share and Like if you have enjoyed this article.

this article is part two of mastering github actions. if you want to learn about part 1 then click here.

https://jamilnoyda.hashnode.dev/mastering-github-actions-part-1

Catch you later, until then keep coding and have fun!
Jamil.