We have a set of jobs (build, push, and deploy) that we would like to run against 3 separate contexts. The jobs are “serial” with each other for a given context; which means push requires build, and deploy requires push. This seems like a prime use-case for matrix jobs. We only need the matrix “param” for the context and the requires property. However, because the jobs themselves are not parameterized, we get an error about unexpected argument. Unexpected argument(s): env
Example:
deploy:
jobs:
- build:
requires: [ test ]
context: com-<< matrix.env >>
matrix: &all-env
parameters:
env: [ dev, qa, prod ]
- push:
requires: [ build-<< matrix.env >> ]
context: com-<< matrix.env >>
matrix: *all-env
- deploy:
requires: [ push-<< matrix.env >> ]
context: com-<< matrix.env >>
matrix: *all-env
- report:
requires: [ deploy-<< matrix.env >> ]
context: com-<< matrix.env >>
matrix: *all-env
Primary question:
How would one leverage a matrix workflow for non-parameterized jobs?
We’ve currently hacked around the limitation by adding the env parameter (unused) to all of the relevant jobs. However, this hack is distasteful (and confusing, since we’re defining an unused parameter). But more importantly, this hack would presumably not be viable when using jobs from an orb that’s out of our control (since we wouldn’t be able to add the unused parameter to the job definition).
Secondary question:
How would one leverage a matrix workflow like this for orb-defined jobs?