@tboerger is correct, the group attribute will not control matrix concurrency. The matrix and parallel features are separate features, used to solve two different use cases. Let me provide a bit more detail to help better clarify –
The use case for matrix pipelines are testing multiple configurations in parallel. For example, you want to test your code using Go 1.5, Go 1.6, and Go 1.7. A matrix configuration essentially creates multiple copies of a pipeline, one for each permutation, and then executes each permutation in parallel. They execute completely independently of one another. This means there is no way for one matrix permutation (e.g. Go 1.5) to wait for or yield to another matrix permutation (e.g. Go 1.6).
The use case for parallel steps (groups) are when you want a single pipeline execution to fan out and then fan back in. For example, maybe you want your Go 1.7 unit tests to run in parallel so that your pipeline executes more quickly.
It is possible to use these features, matrix steps and parallel step execution, together. For example, imagine you wanted to test your codebase against Go 1.5, 1.6, and 1.7. That would be a matrix build. Now image you have a large test suite. You could parallelize your unit tests for each version of Go.
The yaml might look something like this:
- go test ./unit/...
- go test ./integration/...
So how will the above yaml execute? We can visualize what this would look like below:
I hope that helps provide a bit more information about these two independent features, how they work, and how they can potentially be used together.