Functionality to use matrix strategy.

[mattzcarey]

Hi, we are having an issue trying to use the Cypress testing library to run tests. The library lets us run tests in parallel using a matrix. Is there anyway to impliment the matrix in cdk at a job level?

Currently we are resorting to looping over them sequentially, obviously this is not ideal.

Many thanks, Matt

[kaizencc]

Hi @mattzcarey,

can you detail a bit more about what functionality you'd like to see? I assume that you mean this matrix from the github docs. I confess I have never used that before and may need some help understanding your use case.

As always though, you should never be blocked and can use escape hatches to drop down into the yaml level to configure whatever you need.

[mattzcarey]

Hi @kaizencc

We have a set of tests we need to run on all the files in our repo. Ideally we would split up all the files to be tested into chunks and test them in parallel like this as it can take quite a while.

Using matrix strategy, as you linked above, seems like the obvious option. However matrix strategy cannot be perfomed on job steps only on jobs themselves and the property jobs.<job_id>.strategy.matrix would need exposing through the library. Is that something you can do?

In addition I am pretty sure I won't be able to do it with a singular job because we don't want to parallelise the whole workflow inc. dependency checks, build etc. Is there a way to create multiple jobs per workflow pipeline using this library ie. one for the build procedure and a second for testing? Then second job could potentially be parellised using the matrix.

I know that was multiple questions in one but I hope that explains our issue.

Kind regards,
Matt

[kaizencc]

Hi @mattzcarey,

To answer your first question, jobs.<job_id>.strategy.matrix is already exposed through the library via escape hatches -- you can drop down and change anything you want in the yaml file. That is what I suggest for this use case -- the purpose of delivering escape hatches as a feature is so that no one should ever be blocked.

To answer your second question, I'm not entirely sure what the situation is, but it should be that each stage gets its own job in the deploy.yml file. The concept of stages is so that we can set up a beta and test it, before deploying to prod or whatever next step you have in the pipeline. I think you should be able to set up a test stage and a prod stage and then do your matrix-style testing on the test stage only.

Hopefully that is at least marginally helpful.