Refresh after change is submitted via the CQ |
|||||||
Issue descriptionFeature request. Affected Version: 2.13-rc0-312-g9b9adbf What steps will reproduce the problem? 1. On a change ready to be submitted, click "Submit to CQ." 2. Wait for the change to be submitted (e.g. by looking for the email). What is the expected output? The page updates to reflect the current status of the change. What do you see instead? The page continues to say "Submitting to CQ..." forever. Please provide any additional information below. Based on experience from Reitveld, I am used to refreshing the page to see whether the change has been submitted or even to see if trybots have finished. However, in PolyGerrit, Trybot results appear on the page without refreshing, so I was surprised that the page doesn't update after submitting the change.
,
Oct 5 2016
,
Nov 1 2016
,
Nov 1 2016
I think hiding the buttons when CQ is underway with a “Cancel submit” in the case where CQ+2 is set is a good way to go, here.
,
Nov 9 2016
I'm not sure where the best place to do this is. It could be done in the commitqueue.js plugin. That makes sense, as it is in many ways an integration with the CQ. But currently, all that plugin does is modify the list of buttons available to users, and modify the actions they perform. It doesn't have any sort of polling behavior, which would be necessary to implement this. An alternative would be to add it to the buildbucket plugin, which does have polling (to auto-update the set of builds), but that currently only polls buildbucket. It doesn't poll a URL which would determine if the CL has been submitted or not.
,
Nov 9 2016
(P.S. I think andybons' comment in Comment 4 actually applies to issue chromium:644283, which complains about which buttons are available if you refresh the page during a cq run, rather than this one, which complains about whole-page state when you *don't* refresh the page after a cq run is over.)
,
Nov 9 2016
I think adding it to the commitqueue.js plugin is the best place for now.
,
Nov 9 2016
,
Nov 18 2016
I can start looking into this if you have not already started Aaron.
,
Nov 18 2016
That would be fantastic; I've got a couple larger blockers to tackle right now.
,
Nov 18 2016
,
Nov 18 2016
Started work on cl/139608667
,
Dec 5 2016
Submitted https://gerrit-review.googlesource.com/c/92373/ : Add ability for PG plugins to access serverInfo. Out for review cl/139608667 : Refresh after change is submitted.
,
Dec 8 2016
Submitted cl/139608667 : Refresh after change is submitted. It uses the update_delay server config setting, which AFAIK is set to 0 right now. I will ask dborowitz@ how we can get it enabled.
,
Jan 9 2017
,
Jan 11 2017
The fix for the bug is now live on canary.
,
Jan 11 2017
Out of curiosity, how did you know it was in canary?
,
Jan 11 2017
I went to https://canary-chromium-review.googlesource.com/c/426411/ (an unmerged change which loads the cq plugin) and noted that it was no longer giving the mixed-content warning.
,
Jan 11 2017
Ah, the brute force method :)
,
Jan 12 2017
Marking fixed, can be verified after prod picks up the current canary.
,
Jan 17 2017
This is live. Tested by sending https://skia-review.googlesource.com/c/7103/ to the CQ and leaving the tab open. The tab refreshed after the change landed. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by andyb...@chromium.org
, Sep 13 2016Owner: andyb...@chromium.org
Status: Accepted (was: New)
Summary: Refresh after change is submitted via the CQ (was: Refresh after change is submitted)