Having been a Jenkins user in a previous life, I've been burned too often by putting too much logic into the CI configuration, instead of into a build script. In my experience, CI configurations are much harder to debug because you cannot run them without the whole overhead of the CI server/agent infrastructure. I strongly recommend pulling those conditional steps into the build script. Then let the the CI server be responsible for sending in the right build parameters. In case you think I'm just trying to make an excuse for Bamboo, ThoughtWorks recommends holding on "programming in your CI/CD tool" in their January 2015 Technology Radar.
If you have a parameterized build script, then you can leverage Bamboo's notion of capability. For the example you described, you might have one agent on OS X, one on Windows, and one on Linux. You give each agent a custom capability like: my.platform=osx, my.platform=windows, my.platform=linux. Then you call your build script with the capability as a variable. That would look like ${bamboo.capability.my.platfrom}. Note the capability has to be passed as part of a Bamboo task per this question, not embedded in your script. Then tell Bamboo to run the build plan on all 3 agents. The result will be parallel execution across the matrix of platforms.
This is not a perfect analog to Jenkins matrix jobs but it is suitable for the use case above, where there are different environments on each agent. If you have a different use for matrix jobs, it would be helpful for us to hear the details.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.