JasonEtco / ci-reporter

🚧📝 GitHub App to show CI failure logs in PR comments
https://github.com/apps/ci-reporter
ISC License
48 stars 11 forks source link

What is the behavior for numerous failing builds? #37

Open zeke opened 6 years ago

zeke commented 6 years ago

Hi! I think we should give this bot a go on electron/electron org, but would first like to understand what it does when it encounters multiple failing builds, like:

image

Will it comment on the failures for every build? If so, that could get pretty noisy.

JasonEtco commented 6 years ago

TLDR: Right now, it would comment once then update the original comment for each job, as though it were updating after subsequent commits to the same PR.

Good question! There are actually two parts to this:

CircleCI's "wildcard" contexts #36

Right now, its only setup to respond to ci/circleci and continuous-integration/travis-ci/pr status contexts. It should be a wildcard for any Circle jobs.

Account for multiple statuses

Haven't given this much thought, but I'm certainly open to adding some functionality around it. 100% agreed that it'd make for a lot of noise. It's also a little bit tricky, because one status isn't inherently aware of the other statuses of a commit; we'd need to query for the commit and see all the statuses.

Also, when one status reports back as being failed, it'd need to mark the others as still pending in the comment, or wait until they've all reported back.

Tell me how this sounds:

If there is >1 total status with a context of either ci/circleci.* or the Travis context, it would display:


The build is failing

✨ Good work on this PR so far! ✨ Unfortunately, there are some failing builds in {{ sha }}:

ci/circleci: electron-linux-arm `npm test` ``` error log goes here ```
ci/circleci: electron-linux-arm64 `npm test` ``` error log goes here ```
ci/circleci: electron-linux-ia32 Build passed!
ci/circleci: electron-linux-x64 `npm test` ``` error log goes here ```
zeke commented 6 years ago

☝️ that looks great! Looks like browser support for <details> has gotten better since GitHub enabled it, so that's good.

JasonEtco commented 6 years ago

that looks great!

Cool! I don't have the bandwidth to do this anytime soon (probably in ~3 weeks). It's a little involved for outside contributors, but if anyone reading this wants to give it a go then I'm open to it! Otherwise it'll have to wait a bit.