Support inline comments about danger-js

[macklinu]

Regarding danger/danger#684, I'm thinking adding a GitHub review feature could be separate from just adding a { file, line } options hash to the warn/message/fail/markdown functions. I can see value in making one-off comments using Danger as well as integrating into GitHub's review feature. If Danger-rb supports both (or is in the process of doing so), Danger-js can support the same API for parity between tools (we can leave sticky out of Danger-js, though 😃).

Thanks for posting links and explaining the PR Diff positioning system - they will be useful for understand how to parse the diff. A coworker went through a similar experience trying to parse GitHub diffs for an Android static analysis tool he and another coworker have been working on, so I think those could also be some helpful references.

I'm thinking the diff parser could be added to this repo, and if generic enough, it could be pulled out into an npm package for reuse - I didn't see anything when searching npmjs.com that did quite what we need here.

[orta]

We do already have a diff parser in Danger JS - here but what I mean is WRT the diff parser is: You need to take an absolute file path + line, e.g. { file: "CHANGELOG.md", line: 6 } and come back with something that could be found inside the existing diff object that we have e.g. { commit: 918b1dc, file: "CHANGELOG.md", line: 9} or if it wasn't found, then it needs to go inside the main comment.
The API docs will give you a sense of what I mean

Other than that, all sounds fine to me 👍

[orta]

So, from my perspective, I think sticky is something we should avoid. Every Dangerfile that we have at Artsy had sticky turned off on each trigger, which is why I turned it off by default.

Unless someone really, really, really wants it, we should avoid it. It adds a considerable amount of internal complexity (finding all pre-existing violations in every comment / issue before incrementally updating/removing them) on Danger for an occasionally useful feature.

So, file: line:

What would be involved in porting that functionality to Danger-js?

Both of those would work (and be backwards compatible) I think I'm in favour of the options hash. Gives more room for further improvement in the future without making a lot of args on those functions.

Generally the usage of file: line: has been inside danger-rb plugins, where elegance of the code is less important ( you want lots of 2-3 LOC rules ideally )

Implementation:

I see two options here, you can start a review, and make the comments inside there ( see this discussion on what that could look like ) or just outright use the commit API.

Either way, there needs to be

• A "main violations" abstraction that posts the normal GitHub comment (what we have right now)
• A "file violation" abstraction that handlesfile: line: -> PR Diff positioning system

This is by far the most gnarly code in Danger-rb, so I advise taking your time on it and trying to find better abstractions than we have in ruby.

[macklinu]

Thanks @orta, think I misunderstood about the diff parsing thing originally. I'll dive into the code and get my hands dirty. Will open a PR if I have any more questions. 😄

[macklinu]

This issue is open if someone would like to contribute! An initial attempt to solve this was in #99, which might give a starting point. Feel free to comment here to ask more questions or open a PR to get work-in-progress feedback. 😃

[tychota]

I would be pleased to help on this.

At www.bam.tech, we want to use danger as a poka-yoke, to share good practice and learning accros the teams. Inline comment have a big impact on it.

That being said, I have a bad overview of danger js, so maybe it is to complicated for a first task.

My plan so far:

• backport MessagingOptions from #99
• access danger context to get the diff:
  • if the inline comment is in the diff, add the inline object to a list of object and the a summary of inline comment (necessary ?)
  • else do the details summary thing (dear-github/dear-github#166 (comment)) inside the githubResultsTemplate
• if the inline object, implement a review call and inline feedback
• add a setting (env variables/ api) to fallback to use the commit api if the user do not want a review

Does it seems a good plan for you ?

What are the difficult points / points to carefully design the abstraction ?

[orta]

That feels about right, yeah 👍

Here's the main chunk of the work in danger ruby.

I've slowly grown to the idea that I want to see something like #196 which will end up requiring the "did this danger instance create this table" but that's further down the line. Most of the work is in deciding where a comment should go, and making sure every comment is up-to-date when danger does a second run

[macklinu]

Thanks for looking into this, @tychota!

add a setting (env variables/ api) to fallback to use the commit api if the user do not want a review

If it's possible to weave GitHub reviews and inline comments together through some API configuration option, that sounds awesome. I guessed that inline commenting would be the simplest first step, but I'm not familiar with GitHub's API on either of these things, so I'm not sure what would be doable in one PR.

For reference, here is the Ruby PR where the GitHub reviews feature was introduced in Danger - danger/danger#702.

[tychota]

@macklinu @orta: until September 6, I have a bit of vacation and two talks for meetups/training to prepare so it will be pretty busy.

I would definitively have more time after that and your links is so valuable to me. I have now a clearer idea about the work required.

[Rush]

Any progress on this?

[tivac]

@Rush #529

[tychota]

Wow.

[orta]

ah yeah! This can be closed 👍