#53 [RFE] Show number of failed/succeded builds in the status of build
Closed 6 years ago Opened 7 years ago by pvomacka.

When I'm building package for more architectures and one of them fails it shows overall status of the build (in the table on the "Builds" tab) as "Failed". Also on the overview page is written that build failed.
That is actually not really userfriendly for anyone who wants to see the real status of the build. The failed architecture is usually the one which is not so important, but because the build is marked as "Failed" lot of users may overlook it even if the build did not failed on architecture which user is interested in.

Proposed solution:
Show the number of builds (architectures) which failed and number of all builds (architectures).
ie. I'm buidling package 'xyz' on x86_64, ppc64le and i386. Build fails on ppc64le. Then instead of just Failed status, there could be something like '2 of 3 build(s) Succeded' or '1 of 3 build(s) Failed'.


Well, this was discussed several times before. See the links at the bottom.

The problem is that we have also other statuses than just "failed", "succeeded".

We also have have "running", "importing", "starting", "pending", "canceled", etc.

and note that "canceled" state is also terminal so it should probably be included in the final counts.

The current solution is simple and that's good even though I understand it can be a bit tough to get around it.

Metadata Update from @clime:
- Issue assigned to clime

6 years ago

Thank you for comment and links to BZs.

I think that there could be change only in terminal states (the statuses of progress could have some priority and be shown according to its priority - only one status for more chroots even if chroots have different statuses). I did not realized that there is third terminal state ('Cancelled'). Anyway, is it even possible to cancel building on only one chroot in one build job? If it is not, then would it be possible to show "Cancelled" every time the build is cancelled? Only when build is not cancelled, then the number of failed/succeeded builds can be shown.

That could be helpful mainly for people who wants to use the copr repository. I know that current solution is simple, but really confusing and not user-friendly, because in several situation it seems that build fails and there is no functional build even if there are more functional builds than those which failed.

But as I see in BZ, unfortunately all similar proposals were closed as wontfix. Is there any chance that this will be implemented sometime in the future?

Thank you for comment and links to BZs.
I think that there could be change only in terminal states (the statuses of progress could have some priority and be shown according to its priority - only one status for more chroots even if chroots have different statuses). I did not realized that there is third terminal state ('Cancelled'). Anyway, is it even possible to cancel building on only one chroot in one build job? If it is not, then would it be possible to show "Cancelled" every time the build is cancelled? Only when build is not cancelled, then the number of failed/succeeded builds can be shown.

Currently, the behavior is that if a build is canceled, then every chroot is marked as canceled, even it if it was successful. This is probably not what we want, however. Only chroots that were still processing when a build was canceled should be marked as such. Nobody complained about it yet but we might fix that at some point anyway.

That could be helpful mainly for people who wants to use the copr repository. I know that current solution is simple, but really confusing and not user-friendly, because in several situation it seems that build fails and there is no functional build even if there are more functional builds than those which failed.

It's true it can be a bit confusing but it's something we decided to go with for simplicity.

But as I see in BZ, unfortunately all similar proposals were closed as wontfix. Is there any chance that this will be implemented sometime in the future?

I cannot say it will never be implemented but currently I would still vote to keep the current behavior.

This is likely not to happen currently. We might do it in future at some point if have a clear idea how to do it relatively simply.

Metadata Update from @clime:
- Issue status updated to: Closed (was: Open)

6 years ago

Login to comment on this ticket.

Metadata