You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@yetus.apache.org by Nick Dimiduk <nd...@apache.org> on 2019/08/21 19:15:37 UTC
Adjusting the verbosity of test results as posted to bug systems
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
Re: Adjusting the verbosity of test results as posted to bug systems
Posted by Sean Busbey <se...@gmail.com>.
One thing I've seen some folks do for CI results on JIRA is put the
results on the work log instead of in the comments. we could look at
making it easier to do that via yetus. Personally I don't care for it
since I think the vast majority of developers then ignore the
feedback.
On Wed, Aug 21, 2019 at 6:00 PM Allen Wittenauer
<aw...@effectivemachines.com.invalid> wrote:
>
> 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 <bu...@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 <bu...@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 <nd...@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
>
--
Sean
Re: Adjusting the verbosity of test results as posted to bug systems
Posted by Allen Wittenauer <aw...@effectivemachines.com.INVALID>.
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 <bu...@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 <bu...@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 <nd...@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
Re: Adjusting the verbosity of test results as posted to bug systems
Posted by Sean Busbey <bu...@apache.org>.
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 <bu...@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 <nd...@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
Re: Adjusting the verbosity of test results as posted to bug systems
Posted by Sean Busbey <bu...@apache.org>.
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 <nd...@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