search

jruesga / rview

A Gerrit client application for Android
Apache License 2.0
66 stars 21 forks source link

rView does not display the result of the most recent test runs #66

Closed tmmorin closed 6 years ago

tmmorin commented 6 years ago

When issuing a "recheck" comment to gerrit, a new CI test run can be triggered again (without a new patchset). In this case, it seems that rView still displays the results of the first test run (although the results of the other(s) test run(s) can be seen in the comments with "SHOW CI") in the summary showing a list of change, or under "Continuous Integration" in the details of a change.

I'll try to provide an example when I see one again.

tmmorin commented 6 years ago

Despite this minor annoyance, I want to say that rView is a really great app, very well polished and useful ! 🥇

jruesga commented 6 years ago

@tmmorin any public repository/change where I can check this behaviour?

jruesga commented 6 years ago

I guess the repository is OpenStack and i think i found a change (https://review.openstack.org/#/c/490295/) that matches your issue. I will try to fix it.

tmmorin commented 6 years ago

Yes, indeed I saw this frequently in OpenStack, and the change you are looking at is in this case. Thanks!

jruesga commented 6 years ago

@tmmorin after checking how the app is behaving in those, i decided that the app is doing the best thing it can do with the information it had. Let me explain it.

The current behaviour of the app is extract all the CI information from all the messages of the current patchset, and create a list of jobs launched an its statuses, leaving the most recent status in case of several messages having the same job. That means that it displays the last information of all jobs executed for the patched.

An for that made sense, or at least with the information that the app had about the repository, because it doesn't know if the ci robots of OpenStack are filling the information in single or multiple messages (and I know other repositories behaves in a different way).

I'm going to put some examples of some cases i found:

1.- OpenStack

A case where 2 ci accounts are performing jobs in multiple messages. In this case, IMHO, all the attempts (both Jenkins and Zulu) should be aggregated and used as the CI information. So basically, for OpenStack I'm not able to decide if I should use a simple or multiple messages after a recheck

imagen

2.- Gerrit

Jobs comes from the same ci account, but for differect ci subsystems, and I must accumulate both

imagen

So basically, what Rview is doing the "best" for most of the cases. In your case, your last recheck could launch a list of ci subsystems and be all success, but in a previous launch a different ci subsystem failed, so basically for your patchset there are one subsystem still failing. If at least OpenStack's Zulu will release the same ci subsystem, I could try to hack its behaviour, but for me, it is not consistent.