Yup. Custom reports are built using the bugsystem part of the API. They are pretty trivial to write and there are lots of examples.
Some other notes: * one of the benefits of listing everything is also to make sure that what was supposed to get tested actually did. Yetis isn’t perfect. :( * There is a long standing request to Atlassian to provide a way to hide comments by default in their API. The last time I checked it was pretty much in “never gonna happen” state. :(. I don’t know if Github’s API provides something similar. * github PR output is optional and can be turned off entirely if the CI system is properly giving feedback to github. (See, e.g., lf-edge/eve for a real world example). But the ASF limits what Yetus can do to the repos so Yetus is somewhat crippled here. Sent from my ☎️ > On Aug 21, 2019, at 3:27 PM, Sean Busbey <bus...@apache.org> wrote: > > At the moment I believe a project's personality could call > add_header_line and add_footer_table to put stuff before/after the > detailed vote, but it's used across all bug systems. Beyond that, if > we wanted something specific to a bug system I think a project would > have to define their own ejust copying everything an then modifying > the _finalreport implementation. > >> On Wed, Aug 21, 2019 at 2:20 PM Sean Busbey <bus...@apache.org> wrote: >> >> I would love a template since it would mean if we wanted we could >> include more than just a link to the contribution guide (and include >> it all the time rather than just when branch detection fails). oh!!! >> does the github PR api include if the PR is a first contribution? >> because if it does and that's somehow available in the template hook >> then we could include _very_ specific pointers. >> >>> On Wed, Aug 21, 2019 at 2:15 PM Nick Dimiduk <ndimi...@apache.org> wrote: >>> >>> Hi folks, >>> >>> In the projects in which I participate, the Yetus feedback on patch >>> pre-commit is really useful, but it's also extremely verbose. I find this >>> disruptive in a JIRA or a Github PR comment because it distracts from what >>> I see as the primary purpose of those systems: interactions between people. >>> Scrolling through 6+ precommit build reports to find the next comment from >>> a human isn't supportive of collaboration. In short, I think that >>> everything below the "+1 Overall" line should be hidden by default. >>> >>> I'm wondering if the template used to generate the output can be modified >>> such that it leads with the summary but then hides the rest behind a >>> section that is collapsed by default. For instance, I found the >>> details/summary tags [0] for use with Github and the expand macro [1] on >>> JIRA. A related question: how can a project customize the template used to >>> generate these messages back to the bug system? From what I can tell, the >>> report content is built by precommit/src/main/shell/test-patch.sh but I >>> don't see any hooks into a template system. >>> >>> Thanks, >>> Nick >>> >>> [0]: >>> https://gist.github.com/pierrejoubert73/902cc94d79424356a8d20be2b382e1ab >>> [1]: https://confluence.atlassian.com/doc/expand-macro-223222352.html
