<div dir="ltr">Hi!<br><div><br>During last couple weeks there is an increasing demand on tracking 3rd-party CI statuses. We at Stackalytics decided to be in trend and (with some inspiration from Salvatore's proposal) implemented report that shows summary on external CI status. The initial version is available for Neutron - <a href="http://stackalytics.com/report/ci/neutron/7">http://stackalytics.com/report/ci/neutron/7 </a><br>
<br>The report shows summary of all CI jobs during specified period of time, including:<br></div><div> * stats of runs on merged patch sets: <br></div><div>    - total number of runs<br></div><div>    - success rate (success to total ratio)<br>
</div><div>    - time of the latest run<br></div><div>    - last test result<br></div><div>  * stats for all patch sets (the same set as for merged)<br></div><div>  * last test results for every merged patch set grouped by days (useful to see how different CIs correlate with each other and how often they run) <br>
</div><div><br>Under "merged patch set" report means "the last patch set in the merged change request", thus it is almost the same as the trunk code. CI configuration is taken from <a href="https://git.openstack.org/cgit/stackforge/driverlog/tree/etc/default_data.json">DriverLog's default data</a>. Standard Stackalytics screen is also available for CIs - <a href="http://stackalytics.com/?metric=ci">http://stackalytics.com/?metric=ci</a>, including votes breakdown and activity log.<br>
</div><div><br>Since this is the first version there are some open questions:<br></div><div> * Currently report shows results per CI id, but there are CIs that run tests against multiple drivers and this case is not supported. What would be more useful: to get stats for a driver or for CI? <br>
 * Most CIs run tests when patch set is posted. So even if change request is merged within selected time period corresponding CI results may be missing.<br></div><div> * Patterns for non-voting CIs need to be verified. For example Cisco CI now runs 5 jobs, but DriverLog data still contains old data.<br>
<br></div><div>Thanks,<br></div><div class="gmail_extra">Ilya<br><br><div class="gmail_quote">2014-06-16 17:52 GMT+04:00 Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div><div>However, it would be great if we could start devising a solution for having "health" reports from the various CI systems.</div>
<div>This report should report the following kind of information:</div>
<div>- timestamp of last run</div><div>- timestamp of last vote (a system might start job which then get aborted for CI infra problems)</div><div>- % of success vs failures (not sure how important is that one but provides a metric of comparison with upstream jenkins)</div>

<div>- % of disagreements with jenkins (this might allow us to quickly spot those CI systems which are randomly -1'ing patches)</div><div><br></div><div>The percentage metrics might be taken over a 48 hours or 7 days interval, or both.</div>

<div>Does this idea sound reasonable?</div></div><div><br></div></div></blockquote></div></div></div>