This is a minor point, but in the “canvas” view (new and old) and the table to the left in the new view, matrix steps are grouped under a parent step which is the matrix step label without any expansions, for example in a test job I made:
+ deb package: {label}
| deb package: Debian 12 (i386)
| deb package: Debian 12 (amd64)
| deb package: Debian 13 (amd64)
I also tried placing the matrix inside an explicit group step as suggested in one of the release blog posts and/or the manual when I was trying the build matrix out, and the un-expanded matrix group persisted within the explicit group rather than being omitted as shown in a screenshot.
I think it would be best if the expanded matrix jobs were shown as individual steps as per the old build view to make them more discoverable, and if the user wants them grouped, they can add an explicit group step.
Thanks for your feedback on Matrix Steps and wanted to let you know we are currently working on introducing the Modern Build UI, which is a blend of both the Old and New UI. This includes changes to the Matrix Steps which look to match what you mentioned.
Read more on the Modern Build UI, test out the prototype and leave feedback - here
I had a look at the prototype linked from that page, I’m not too clear on where the “Test Matrix” group around the matrix steps is coming from - I’m assuming it isn’t a group step due to the “Matrix step” text to the right of it. It also mentions the canvas view won’t be changed from how it currently is?
Jumping on this from a different timezone. You have identified a known rough edge the team is actively thinking about.
A few things worth knowing:
The “unexpanded” parent entry (e.g. deb package: {label}) represents the matrix step as a whole, and its state determines whether downstream dependencies can run. So it’s not purely decorative, removing it entirely could obscure important pipeline state information.
When you switch to Display: State mode, matrix steps un-nest from their parent grouping, so you’ll see the individual jobs listed directly rather than nested under the parent. That might get closer to what you’re looking for if you haven’t tried it already.
Happy to keep the conversation going here for any other suggestion you may have.
The downstream dependencies is a point, although I feel that could be communicated equally well by showing each of the expanded steps as a node in the tree, and only grouping when an explicit group step is used, so the following pipelines would be functionally equivalent, and the first two would be displayed exactly the same in the UI:
Ungrouped matrix pipeline:
steps:
- label: A
key: A
command: true
- label: "B{{matrix}}"
key: B
depends_on: A
matrix: [ 1, 2, 3 ]
command: true
- label: C
depends_on: B
command: true
Separate steps:
steps:
- label: A
key: A
command: true
- label: B1
key: B1
depends_on: A
command: true
- label: B3
key: B2
depends_on: A
command: true
- label: B3
key: B3
depends_on: A
command: true
- label: C
depends_on: [ B1, B2, B3 ]
command: true
Grouped matrix steps:
steps:
- label: A
key: A
command: true
- group: B Group
key: B
depends_on: A
steps:
- label: "B{{matrix}}"
command: true
- label: C
depends_on: B
command: true
I could be looking in the wrong place, but the “State” display mode is still showing the matrix steps grouped together. At a minimum, I feel a separate label for the implicit group vs. the inner steps would aid documentation and be good enough for me, although I still think making the (visual) grouping dependant on an explicit group step would be better.
Catching up on this conversation. Thanks for your detailed feedback on the build matrix grouping. We have, however, specifically mentioned in our docs that matrix elements are grouped automatically - Build matrix | Buildkite Documentation. I can pass your suggestion to have an option to show expanded matrix jobs as individual steps, with grouping left to explicit group steps, as a product feedback. I’ll raise it with our product team to assess.
,