"Bruns, Curt E" <[email protected]> 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 _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
