feature request: add option for increased logging for debugging

[cdaringe]

problem

I have a variety of hits against my gkk instance, many of which I expected to result in a merge. I would like to configure my instance to get loud in the handler s.t. I can more easily diagnose why the merge was omitted/failed. the server logs as they stand do not yield (or allow to yield) any diagnostic information.

discussion

in either route, more logging points would need to be inserted into the handler and maybe some of the utilities consumed by the handler?

there are a few options:

• enable configuring hapi logging levels, ideally from the ENV s.t. it works w/ the reference instance
  • trouble w/ this approach is that one must pass the logger around, perhaps into places where it may be awkward
• debug.
  • this is my personal preference, as it's ubiquitous in our community. easy adoption, well known usage pattern

[travi]

logging is certainly an area that could use some improvement, so i'm very open to input and contributions in this area.

however, with travis's recent announcement about deprecating their use of the commit status api, we may be forced to move greenkeeper-keeper from being an OAuth app to a GitHub app, which is why I've started to look into a Probot implementation.

I bring this up because it is unclear how much change we will need to handle to support probot and if it will even be worth continuing to support a hapi version once that one is available. Probot does include bunyan, so i lean toward an approach that would support bunyan across the board. I do like debug, but i have been unsuccessful figuring out how to get debug streams to be combined with the bunyan stream in the other hapi apps i maintain (i'd love to understand this piece if you have figured it out).

are the things you are trying to debug possibly related to the travis changes? i have noticed that they are limited to projects managed by travis-ci.com rather than travis-ci.org, so it mostly impacts private projects.

[cdaringe]

however, with travis's recent announcement about deprecating their use of the commit status api,

hmm. i interpreted that to imply for us that we just need to hit a different api route and possibly derive readiness-to-merge slightly differently as consequence of the api shift. should still be oauth friendly, and there's no mention of github stopping using the status event. did i miss anything?

I've started to look into a Probot implementation

nice! probot looks really neat. had never heard of it until now. im not sure what it brings over the status quo, beyond auth via gh app? anyway, looks nice. i may try that out next time im GH hacking.

Probot does include bunyan, so i lean toward an approach that would support bunyan across the board

ya, makes sense

debug streams to be combined with the bunyan stream in the other hapi apps i maintain

im not sure there is a great way, assuming you mean something akin to "get debug calls to pipe into ". given that it's not intended to be demuxed, one would have to squash process.<stream>.write streams, buffer, inspect, and re-pipe, or monkey-patch a debug internal, which im not sure is even exposed.

are the things you are trying to debug possibly related to the travis changes?

no. i use circle, codeship, and unrelatedly, gitlabci.

[travi]

i interpreted that to imply for us that we just need to hit a different api route and possibly derive readiness-to-merge slightly differently as consequence of the api shift

that was my interpretation early on as well, which is why i haven't made it a priority yet. however, i'm getting a different impression as i look deeper. part of the difference between oauth apps for github and github apps is the level of granularity that scopes are defined, so it seems the scope for access to the check_runs and check_suites stuff seems to be limited to github apps only. i don't see the scope available when configuring a personal access token. its also a different webhook, but that piece appears to be available in the webhook config.

no. i use circle, codeship, and unrelatedly, gitlabci.

fair enough. you'll probably be best looking into this on your own for now then. my focus will be mostly on figuring out the check runs details as soon as i find some time to dedicate to it, so i wont have a chance to think about more logging until thats further along. i'm happy to provide feedback if you open a PR though and should be able to respond w/in a day or so. i don't want to be a roadblock if youre needing some progress to figure out any issues.