This functionality is intentional as the builds index page is intended as an overview of the build and for more details you can click a build to view the full set of steps.
It’s also a little complex to calculate the grouping on the index page since we have to load so many builds and many steps, we limit the number of steps per build for performance reasons. This means we cannot accurately calculate the groups in order to display them on this page as they steps are truncated.
Interesting. It feels like the grouped version of the UI is a nicer overview than all the ungrouped jobs of a build, though. (It is almost the only reason I want groups at all, honestly).
Only the first 100 jobs within a build header can ever be displayed in the UI, so you might not see all of your groups at all times. However, the jobs are fine and will still show up on the build page.
@jarryd I see! Thank you! Do you think maybe that could be clarified a bit?
Only the first 100 jobs within a build header can ever be displayed in the UI
Might be better as
Only the first 100 jobs within a build header can ever be displayed on the builds index page
Second. I think I have a feature request to display the groups on the builds index page. Not all jobs would have to be displayed. Would it be possible to display the denominator as unknown or ??, or similar? Like:
| category a | | category b |
|------v-----| |------v-----|
| 50/unknown | | 20/unknown |
Oh, I also think there may be another bug or inaccuracy. My jobs became ungrouped on the build index page when there were only 66 total jobs in the build.
Ah yes, we are aware of that bug in the UI. Did this happen whilst a build was running? Ie after it had been updated. There is a bug we have yet to squash related to build updates coming in through the websocket and updating the index page and it manifests in what you have seen.
I don’t have a time estimate for when we will be looking at this bug though.