Last modified: 2014-11-19 21:55:47 UTC
Sometimes it can take up-to 10min for a newly committed patch set to appear in the in Jenkins job queuing or even longer being executed (happens when several core jobs being executed). Is there a way to give a more accurate update about the current commit/testing status in Gerrit (and its unit tests) instead of manually checking [1] because I have experienced that even in [1] it can take a while until tests are actually appear. The questions is not about being able to see results but being able to see that a testing request is being queued/worked on and not lost somewhere. [1] https://integration.wikimedia.org/zuul/
Zuul exposes its status via https://integration.wikimedia.org/zuul/status.json which can then be used by a JavaScript to add a status somewhere in Gerrit interface. Change https://gerrit.wikimedia.org/r/#/c/60662/ made to Wikimedia Gerrit repository let us inject Javascript in Gerrit. So we need: - to write some javascript - enhance Zuul status.json to accept queries for a given change
Needs Zuul status.json page to be updated: bug 47609
This is still a valid enhancement request, it is still blocked by bug 47609 that we can start implementing whenever Zuul is upgraded on Wikimedia installation. Once that is done, we could provide the status of change and add some Javascript magic in Gerrit interface to show the build progress.
Pending someone to implement the relevant code in Zuul status page/Gerrit customized javascript.
Created attachment 16958 [details] json result for /status/change/170067,1 We can now fetch the status of an individual change using: https://integration.wikimedia.org/zuul/status/change/170067,1 See attached output for an example. That feature has been added upstream recently and deployed on production. Was Bug 47609 - [upstream] Zuul: status.json API should be able to filter by change
Also, since the creation of this ticket, we've built the visual dashboard: https://integration.wikimedia.org/zuul/ Which allows one to see where it is in the queue and how long it'll take. And in general these kind of delays usually relate to downtime. When things are up, the delay isn't worth building an infrastructure for so I'm wontfixing the request for communicating the delay back to Gerrit (or Phabricator). It'll be there when it's there.
