
TravisBuddy: Adds comments to failed pull requests, tells author what went wrong - bluzi
https://github.com/bluzi/travis-buddy
======
diggan
This will get messy quickly if you have a PR that you are adding commits to
and have a failure for each commit. This has the same problem as some code
coverage solutions, they are spamming the PR with comments that are only
important for a few moments, then they are just noise...

Speaking about finding test failures quickly though, Jenkins and many others
(except ALL the cloud/SaaS solutions?) actually parse test results via junit
or similar to show you failures easily. I'm wondering why more SaaS don't do
this?

See an example here (for our js-ipfs project):
[https://ci.ipfs.team/blue/organizations/jenkins/IPFS%2Fjs-
ip...](https://ci.ipfs.team/blue/organizations/jenkins/IPFS%2Fjs-
ipfs/detail/fix%2Fremove-unused-var/2/tests)

It's so much easier to find test failures now and doesn't involve leaving a
comment on the PR. It's simply two clicks to find this view from a PR (click
the status message, click on "tests")

~~~
bluzi
Thanks for the feedback, we're working on methods to prevent TravisBuddy from
commenting if the PR is being rapidly updated or if its comments are not
relevant for some reason. One idea is that if the PR has a special label
TravisBuddy won't comment on it. Another one is to be able to communicate with
TravisBuddy using comments, so when you're sick of it you could just comment:
"@TravisBuddy stop", and it'll stop immediately. (Maybe even "@TravisBuddy
clear" to remove the previous comments)

Yeah, Jenkins' tests view was one of the inspirations for TravisBuddy :)

~~~
neebz
You can do what codecov does; They keep updating the same comment with the
latest result.

~~~
bluzi
That's an awesome idea, will be a feature for sure.

------
dotsh
Idea is great but this logo looks like evil douchebag kind of guy with this
tagline "Not the bot you deserve, but the one you need" doesn't look great.
You definitely need to work on your brand. :)

~~~
7Z7
Came here to comment exactly this. The expression on the face is expressing
all the wrong messages about the service.

~~~
kemayo
It also seems to be the avatar for the account that leaves the automated
comments on the pull requests. I suspect it can cause a subliminal "this is a
jerk" response in the author of the pull request who you'd probably prefer to
feel receptive to this feedback.

------
bigblind
I really like this idea. I think more tools should integrate into GitHub this
way. The status API is nice, but you always have to click through to get the
details.

I think you could do something similar with code analysis tools, so they make
review comments in the code where issues occur.

~~~
ddm379
I know this is nit-picky, but I'm not a fan of how the "Details" link opens in
the same tab.

~~~
bluzi
Not sure what do you mean

------
matchai
For those not using Travis, ci-reporter supports CircleCI too, and is
extensible to support any other CI platform.

[https://github.com/JasonEtco/ci-reporter](https://github.com/JasonEtco/ci-
reporter)

------
dandigangi
Really cool! I'm going to give it a try. I've been looking to build our Travis
CI more in-depth.

------
TomK32
Cute little list on the example screenshot. _looks at own code with some 3300
tests_

~~~
bluntfang
I'm not a travis user, but with Jenkins there is an xunit plugin that opens up
an api with test results for the specific build. since xunit formatting is
standard/generic, we've implemented a parser that just gets the # of
pass/failed tests and links to the build for further investigation.

We had a similar problem where posting all of the results was just more noise
than useful, this is at least a good starting point for handling build result
feedback.

