Open Stack

Darragh Bailey <daragh.bailey at gmail.com> 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