More group merging questions

We have a pipeline that is entirely dynamically uploaded. So in our pipeline.yaml we have this:

  - command: "" uploads the jobs. It uploads enough that we would love to group them together. It uploads more yaml like:

  - group: "category 1"
    depends_on: []
      - command: ""
  - group: "category 2"
    depends_on: []
      - command: ""

Which are nicely grouped into category 1 and category 2 on /{org}/{pipeline}/builds/{build-number} but show up ungrouped on /{org}/{pipeline}/builds.

Note that there is no way to know in advance which groups will show up, so we cannot “just” put the groups in pipeline.yaml.

How do I get my nice groups on /{org}/{pipeline}/builds?

Hi @john.soo thanks for the question!

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).

Is this the point mentioned in the group step docs?

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.

Yeah thats it exactly! :+1:

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.

1 Like

Hm, I am not sure, sorry. It is definitely permanently ungrouped on the build index page now, though.

Hey @john.soo!

We received some clarification from the team, and the job truncation limit is actually 50, not 100!
We’ll update the docs with this info.


Woo! Thank you!