Open Stack

"Bruns, Curt E" <curt.e.bruns at intel.com> writes:

> Problem Statement:
> When a review fails pep8 style checks, a developer has to dig through
> the logs to figure out what failed.  e.g. In this review
> https://review.openstack.org/#/c/151737/, there is a pep8 failure. A
> developer has to click on the Jenkins gate-cinder-pep8 link, then the
> console.html.gz log, then search for errors.
>
> As a developer, to help speed up development, it would be beneficial
> to have style check failures to be inserted as comments in code
> reviews.
>
> Example: Style Check failures showing up as inline comments:
> http://review.whamcloud.com/#/c/13402/1/lustre/tests/parallel-scale-cifs.sh
> (HPDD Checkpatch auto-generates style check messages) I talked to the
> Intel folks and they used the Linux Checkpatch PERL script as the
> starting point :
> http://lxr.free-electrons.com/source/scripts/checkpatch.pl
>
> Would be great to have something similar in OpenStack.
>
> Text above straight from:
> https://etherpad.openstack.org/p/styleChecksInReviews
>
> I’m willing to work on the feature if there are some suggestions on the best way to do it.

I think this is potentially a useful thing; though, if the goal is
specifically to speed up development, probably the easiest thing is to
set up a configuration that highlights style errors in real-time in the
developer's editor.  Such configurations already exist for many common
editors and IDEs.

But assuming that we think it's still useful, or just really neat (this
is also potentially useful for coverage, for instance), here's what I
think a possible implementation might entail:

* Some component that can run after a style (or coverage, or ...) job
  that will take the output of that job and convert it to a standard
  format for line annotations.  I don't know if such a format exists
  already; that should be researched.  If not, we can make one fairly
  simply.  I imagine a mapping of file-line to comment entries, probably
  in JSON.  This component should be a simple stand-alone program or
  script.

* A way to transmit that back to Zuul as part of the job result.  That
  means one or more of these:

  A) A Jenkins plugin to read them into memory and an enhancement to the
  jenkins gearman plugin to return that as part of the job result.

  B) Same as A, except doing both parts in the gearman plugin (might be
  more convenient, but it feels like feature creep for the gearman
  plugin).

  C) An enhancement to turbo-hipster to read that data and return it to
  Zuul as part of the job result.

  Our long term goal is to stop using Jenkins and use something like
  turbo-hipster instead, so (C) is the best option if we can be patient
  and wait for that transition; if we want something immediately, we
  would probably need to do (C) and (A or B).

* An enhancement to Zuul that looks for that data (possibly JSON blob)
  in the returned payload from a job, and if so, includes that
  information when reporting on a change.  Comparatively speaking, this
  is the easy part.

The reason we can't do the approach in use at Intel is that our test
workers are completely untrusted (because they run un-reviewed code
submitted by people on the Internet) and therefore, they don't have the
necessary credentials in order to leave comments in Gerrit.

-Jim