Display multiple Copr builds for TF results if present

[lbarcziova]

In packit/packit-service#1658 there was implemented that a TF run can be triggered with multiple Copr builds and API for TF runs changed (copr_build_id -> copr_build_ids) as well. This PR implements displaying those builds correctly in the TF result view.

Related to packit/packit-service#1658

The view for the TF runs with only one build stays the same and this is how it looks like for TF runs with more builds:

---

RELEASE NOTES BEGIN
N/A
RELEASE NOTES END

[softwarefactory-project-zuul]

Build succeeded.

✔️ pre-commit SUCCESS in 2m 19s

[softwarefactory-project-zuul]

Build succeeded.

✔️ pre-commit SUCCESS in 1m 44s

[softwarefactory-project-zuul]

Build succeeded (gate pipeline).

✔️ pre-commit SUCCESS in 1m 50s

[lachmanfrantisek]

I know I am a bit late to the party, but can't we add more info to the labels? The numbering does not have any real meaning...
(I really like that you've changed the visual style from the pure text.)

What about something like this?

Or maybe even with the numbers to be explicit?

Or use this syntax just with the extra build but that could complicate things.

@mfocko Do you know what is the difference between this and pipelines that we've lost the space between the labels?

[lachmanfrantisek]

And I've forgotten to mention that this whole feature is really amazing! 🚀

[mfocko]

@lachmanfrantisek I think that in pipelines it's wrapped one more time in LabelGroup 🤔

[lbarcziova]

@lachmanfrantisek the reason why I didn't want to do it that way was that it would require an additional API call since in the response for TF model we get only Copr build IDs. I was thinking about displaying the IDs instead of Build 1, 2, but on the other hand, the Copr build IDs are IDs in our DB which also does not make that much sense to show. Do you think it is worth it to do additional API calls/ changing the API so that we can display the PR number for the additional build (since you can see more info about the build right after clicking on the link for the build)?

[lachmanfrantisek]

I am not sure if it is worth that extra call... Personally, it sounds logical to know what are these builds about and which one is the core one and which one is the extra one (what we don't know here without other calls, do we?). But we can leave it as is and see if anyone will ask for it...

[TomasTomecek]

Can we enhance the existing API call so it includes the additional info and we wouldn't need to perform extra API calls?

[mfocko]

why does the page load for so long /o\ :peek:

[lbarcziova]

Can we enhance the existing API call so it includes the additional info and we wouldn't need to perform extra API calls?

It is an option (as I already wrote in the previous comment - changing the API), but the additional processing would be still there, just directly in the packit-service code and I'm not sure I like that kind of API design. I would wait for some feedback and we can revisit/even discuss on arch.