Darragh Bailey <[email protected]> writes: > Hi, > > Currently the main issue from end users, is the user experience around the > UI when looking at job results once the run is complete, and to a lesser > extend looking at your jobs in the zuul status page when running. > > I'm wondering if there is a plan to have a full UI covering both historical > job runs for projects as well as live status reporting?
Yes, Tristan has started work on that, and we plan to continue it after we migrate openstack to Zuul v3. > I've noticed there is an SQL reporter, should that be leveraged to provide > access to the sort of information that needs to be tracked? Or should > something else be used such as simple files to identify success/failure? Yes, we plan on using it to supply the historical data. > 1) Project status view: > > The main status page can be useful for those supporting zuul in an > environment to have a quick overview of everything, however feedback we've > received locally suggests most developers are frequently only interested in > a single project and find this to be overwhelming This suggests there > should be a per-project status view, showing only the pipelines and changes > of interest for a single project, along with any CRD that are linked. > > Possibly under an endpoint of "/<project>/" as the default view showing any > pipelines relevant to the project along with any changes going through them. That sounds reasonable once we have the new web framework in place. > 2) Project build history view: > > Returning links at the end of a run in a comment to the raw log files as > the only build history is somewhat jarring for people used to the > Travis/Drone/Circle CI services available, there's the expectation that it > should be easily to see the previous runs, seeing whether they passed, > which jobs within a set failed, and to display the detailed log when > desired. Providing a reasonable UI is becoming a pre-requisite for > adoption, no matter how good the functionality, it can be difficult to get > acceptance if the "form" is deemed limiting (non all follow this, but it > does seem that some of the most vocal objectors can fall into this area). I'm a little confused by this one. I agree they should be available, but I think they already are. Zuul currently provides (in a comment, as you say) the overall pass/fail status of the build set, the pass/fail status of individual jobs, that same information for previous runs on the change, and links to the detailed logs. In Github, the presentation of that available to us is somewhat limited, but I think in Zuul v3 we're approaching a reasonable compromise. Note this may be significantly different that what you are running. If you're suggesting that there should *also* be a way to find that information from a main Zuul web page, yes, I think that would be covered by the previous point. I would like to point out though that Zuul's primary user interface always has been, and will continue to be, the code review system. That's on purpose. The recognition that a developer should have all the information about a change, including test results, at their fingertips is one of the earliest innovations in Zuul; only now are facilities appearing in Github *and* Gerrit to support this the way we've always wanted. The web interface will be a complement, not a replacement, for this. That doesn't mean the on-change reporting is frozen, we will happily continue to improve the UX there (especially with the new tools available to us). > 3) Change view > > Users of tools such as GitHub are expecting a link to appear on the PR > status checks that can then be followed to see the state of the job(s) > currently executing. Currently this can be enabled through setting of a > config option "status_url_with_change" in the zuul section. This can also > be used with Gerrit making it easy to quickly see a single change. That config option does not appear in my tree. However, I believe the Github support in Zuul v3 already supports what you describe. > Are these of any interest? > > I'm no UI expert, so I'm just identifying some of the pieces that we hear > feedback over and hoping that if I can help get the necessary information > exposed and appearing at the right places someone else might know how to > make it look nice.. Thanks for the use cases. I think what you're looking for is not radically different than the rest of the team. It may be helpful for you to start testing Zuul v3, as I think some of the areas you're finding rough edges are different there. Once you do so, I'm sure I and others will be happy to help work out any remaining issues. Expect effort on the historical web interface and rest API to begin after OpenStack migrates to Zuul v3. It'd be great if you can pitch in on that with either reviews or code once we get going. None of us describe ourselves as javascript developers, so we aim to keep that area pretty accessible. -Jim _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
