Matrix variable does not work in needs keyword

I have a build matrix over a certain amount of build types. Then I want to create a job that tests those builds but each test job depends on the build of the same type so I tried:

test:
  strategy:
    matrix:
      type: [normal, extra, nox]
  needs: build-${{ matrix.type }}
...

However this results in an error saying

Unrecognized named-value: 'matrix'.

Is there a way to create a template like this given we cannot templatize the needs keyword?

2 Likes

Github workflow yml doesn’t support use ${{matrix.xx}} in needs keyword. I would suggest you to specific all jobs name into the matrix job > needs keyword.

For example, you have jobs: build-normal , build-extra and build-nox.

In test job with matrix, set

needs: [build-normal, build-extra, build-nox]

Then the matrix jobs will start after all the dependences jobs completed.

That will work but it’s not perfect as it will delay the workflow since if build-normal is faster to run than build-extra, test-normal should start straight after build-normal and not only after all build types have finished. I understand this is a limitation and therefore will accept your answer.

2 Likes

You can simplify it to just specify needs: [build], but yes I haven’t found out a way to for it to start the next job until ALL of the matrix jobs have complete.

Has anyone else? 

Hum, I am confused and I am getting a different behaviour where GitHub Action waits for all builds to be finished before moving.

https://github.com/comit-network/comit-rs/runs/611097751?check_suite_focus=true

As you can see here: https://github.com/comit-network/comit-rs/blob/924964c5ec07aa189d885ad36dd5e60f7166f76e/.github/workflows/ci.yml#L94

I have needs: build

When I actually would like, similar to OP, to start the second step whenever the first step is done for a given value in the matrix.

1 Like

Same confusion over here. Just because the Windows runner is slow I shouldn’t have to wait for test feedback on the Linux runners. :confused:

In fact, why can’t we set a strategy/matrix for the whole workflow? That could implicitly solve this issue (in some cases), since then (or so I would imagine) all job names are scoped to the current matrix entry.