Inline mode. #529

sunshinejr · 2018-03-04T18:41:31Z

~~(Because this is basing off of #516, I'm currently targeting it's branch to see actual changes, when it's merged I'm gonna switch it back)~~

Live demo: Harvey#17

Todo:

…e_line_api # Conflicts: # source/platforms/GitHub.ts # source/runner/Executor.ts

orta · 2018-03-05T15:27:42Z

scripts/danger-dts.ts

-  const dslFiles = fs.readdirSync("source/dsl").map(f => `source/dsl/${f}`)
+  const dslFiles = fs
+    .readdirSync("source/dsl")
+    .filter(f => !f.startsWith("_tests"))


orta

Great progress

orta · 2018-03-05T15:43:20Z

source/danger.d.ts

+    /** Git diff chunks */
+    // Not sure if this is the right place for this one, but few methods needs both chunks & text diffs and I didn't want to parse two times the same file
+    // We could rename the interface, but couldn't find a good one
+    chunks: any[]


interesting, I wonder if the object still has the same shape with the bitbucket support

orta · 2018-03-05T15:44:31Z

source/danger.d.ts

+  }
+
+  export function isInline(violation: Violation): boolean {
+    return violation.file !== undefined || violation.line !== undefined


I wonder if outright enforcing both is probably the right call here, then you can make safe assumptions inside the inline side of the code, which is already gonna be complex

I agree, this is like the first line I wrote and after the whole PR I definitely think this is a right call. Gonna fix.

orta · 2018-03-05T15:46:12Z

source/danger.d.ts


  /**
   * Adds a message to the Danger table, the only difference between this
   * and warn is the emoji which shows in the table.
   *
   * @param {MarkdownString} message the String to output
   */
-  function message(message: MarkdownString): void
+  function message(message: MarkdownString, file?: string, line?: number): void


any chance you can add the @params - something like:

* @param {MarkdownString} message the String to output * @param {number | undefined} file a file which this message should be attached to * @param {number | undefined} line the line which this message should be attached to

orta · 2018-03-05T15:46:35Z

source/dsl/DangerResults.ts

@@ -26,7 +25,7 @@ export interface DangerResults {
  /**
   * Markdown messages to attach at the bottom of the comment
   */
-  markdowns: MarkdownString[]
+  markdowns: Violation[]


yeah, I should have done that from the start - thanks

orta · 2018-03-05T15:50:45Z

source/dsl/DangerResults.ts

+      }
+    }
+  }
+  Object.keys(results).forEach(violationsIntoInlineResults)


does this do something?

Oh, yeah. So this line does iterate through results keys (warnings, fails, messages, markdowns) and for each kind it generates violations for inline results and appends to a variable initialized before. This whole function is a tough one, I needed to transform DangerResults into DangerInlineResults[] and I couldn't find a nicer way. Basically a transformation from:

{ fails: Violation[], warnings: Violation[], messages: Violation[], markdowns: Violation[] }

to

{ file: string, line: number, fails: string[], warnings: string[], messages: string[], markdowns: string[] }

I'm all ears if you have something better-looking in mind 😅

Ah, I guess you have to mutate the results object? Yeah, that's a bit of a toughie, maybe it just needs a comment saying what's happening

Added a comment - let me know how it looks!

Yep, that's good

orta · 2018-03-05T15:55:04Z

source/runner/Executor.ts

+      const inline = inlineResults(results)
+      const inlineLeftovers = await this.sendInlineComments(inline, git)
+      const regular = regularResults(results)
+      const mergedResults = sortResults(mergeResults(regular, inlineLeftovers))


great work on handling the leftovers, thought I would have this bring this up 👍

sunshinejr · 2018-03-06T09:09:46Z

Also, @orta, I would need an advice on what should be a default behavior for inline comments after each commit. Should we delete all of them and create new ones in it's place? Should we update existing ones? Should we only remove the ones that are not present in the newest commit?

Oh, and how about the template that we use for inline comments? Right now I'm using the one for main comment, but it seems kinda stacked (maybe remove headers?)

orta · 2018-03-06T12:29:20Z

I'm not too worried about the template for the inlines, every time I've seen someone use it, it's been with markdown so they get full control.

However, a smaller version could just be a markdown list instead:

🚫 Jk
🚫 Fix it bro
⚠️ Bad empty line!

<!--
  2 failures:  Jk, fix it bro
  1 warning:  Bad empty line!
  1 messages
  
  DangerID: danger-id-default;
-->

- :no_entry_sign: Jk
- :no_entry_sign: Fix it bro
- :warning: Bad empty line!

I'd be fine with it skipping the "posted by danger" too. So you could definitely improve that.

orta · 2018-03-06T12:39:26Z

Re: comments, yeah, ideally edit, I know it's a bunch of work but it triggers a lot of emails when comments are deleted and re-created.

Perhaps you could extend the current danger-id to include file and line per message. This means lookups in the existing comments list should be pretty simple:

you can mark all of the inline comments as to be deleted
then as you edit a comment it gets removed from that list
once all danger results have been handled, delete the comments that haven't been edited

…e violation

sunshinejr · 2018-03-06T16:37:46Z

@orta that's a great point, didn't think about the emails. It's gonna take more time, but I think it's worth the cause.

Oh, and found a few secs to update the inline comment template with tests. Simple bullet points are even better than a table with rows, should look much cleaner.

Edit: Forgot about BitbucketServer comments, gonna add them as well in a few (even though we won't support it in the beginning, no problem adding a core prepared for implementing api endpoints)

Edit2: BitbucketServer inline comments template added as well

sunshinejr · 2018-03-18T17:48:28Z

@orta I think I’m kinda satisfied with it, should be ready for the final check. I refactored chunks from TextDiff, so it has a separate function to get it now (structuredDiffForFile).

The only thing I’m not sure about is that passing gitDSL around. Runner -> Executor -> Platform -> GitHub all have it just to get a diff on a file (right now also a commit hash, but it can be fetched from a platform I believe). If we could somehow get a gitDSL (or just chunks for each fil) in platforms(GitHub and now BitBucket), it should be all cleaner. But it can be refactored later of course.

I would also love some help with docs, not sure where to even start 😅

~~Disclaimer: I haven't fully tested the latest version on Harvey, as we have a problem with CircleCI right now, thus I would wait a bit before a final merge anyways.~~

Update: I've tested it on Harvey, as the problem was fixed a few minutes ago, and it seems like removing/updating comments is working correctly! 🎉

orta · 2018-03-20T11:08:48Z

OK, this is cool - I'll handle all the docs side, but I'm on a deadline (for tomorrow) so will take a serious look at the weekend and update this PR. 👍

Awesome

orta · 2018-03-25T22:59:28Z

source/commands/utils/runDangerSubprocess.ts

  let processName = subprocessName[0]
  let args = subprocessName
  let results = {} as any
  args.shift() // mutate and remove the first element

  const processDisplayName = path.basename(processName)
+  const dslJSONString = prepareDangerDSL(dslJSON)
  d(`Running subprocess: ${processDisplayName} - ${args}`)


cool, - this makes sense!

orta · 2018-03-25T23:02:34Z

source/danger.d.ts

+    markdowns: string[]
+  }
+
+  export const emptyDangerResults = {


These are in the danger.d.ts - will need to remove these for prod

orta · 2018-03-25T23:19:51Z

source/platforms/github/GitHubAPI.ts

+    const prID = this.repoMetadata.pullRequestID
+    return await this.getAllOfResource(`repos/${repo}/pulls/${prID}/comments`).then(v => {
+      return v.map((i: any) => {
+        return { id: i.id, ownedByDanger: i.user.id == userID, body: i.body }


I think this will want to also have a danger-id check (could be reasonable to imagine many dangers posting inline)

orta · 2018-03-25T23:21:48Z

source/runner/Executor.ts

@@ -162,7 +181,8 @@ export class Executor {
   *
   * @param {DangerResults} results a JSON representation of the end-state for a Danger run
   */
-  async handleResultsPostingToPlatform(results: DangerResults) {
+  // TODO: Instead of danger, pass gitDSL


this got did - I think?

orta · 2018-03-25T23:23:33Z

source/runner/Executor.ts

+        resolve(dangerResults.reduce((acc, r) => mergeResults(acc, r), emptyDangerResults))
+      })
+    })
+  }


this is some 👍 code

orta · 2018-03-25T23:25:18Z

source/runner/_tests/_executor.test.ts

+    expect(platform.updateInlineComment).not.toBeCalled()
+    expect(platform.createInlineComment).toHaveBeenCalledTimes(2)
+    expect(platform.deleteInlineComment).toHaveBeenCalledTimes(2)
+  })


solid tests

orta · 2018-03-25T23:27:15Z

source/runner/templates/githubIssueTemplate.ts

+${results.messages.map(printViolation("book"))}
+${results.markdowns.map(v => v.message).join("\n\n")}
+  `
+}


orta · 2018-03-26T02:05:37Z

Conceptually, this is basically good to go 👍 ! Code-wise and architecture-wise I'm happy, but I've run out of time this evening and haven't managed to successfully get an inline message to appear. So good in theory, but doesn't look to be fully hooked up in practice yet.

I'm reasonably sure that my changes won't have broke it anyway 👯‍♂️

sunshinejr · 2018-03-27T18:45:40Z

Okay, I'm investigating. Added logging to the PR, gonna remove it after the investigation.

~~Gonna need to figure out where is the Danger log, though 😅~~ Okay the log for Danger is for sure in the Node.js:node build on Travis, so I'm gonna use this one.

Seems like the structuredDiffForFile returns NULL, so the diffForFile would do as well. That's why we couldn't find a position for inline comment and that's why the inline comments are in the main comment (our fallback for inline comments that are not a part of PR). Now we need to know why we don't have a diff 🤔
Seems like Danger executes wrong URL for PR (diff):
https://api.github.com/repos/sunshinejr/danger-js/pulls/529
instead of
https://api.github.com/repos/danger/danger-js/pulls/529
TRAVIS_PULL_REQUEST_SLUG might be the answer (instead of TRAVIS_REPO_SLUG), let's see. From the docs TRAVIS_PULL_REQUEST_SLUG is empty for a push build, not a PR build, so it's not that safe - we might want to use TRAVIS_PULL_REQUEST_SLUG when possible and switch to TRAVIS_REPO_SLUG otherwise. TRAVIS_REPO_SLUG is fine, investigating further.
Okay, seems like down there somewhere there is no repoSlug and then it is created by github.pr.head.repo.full_name. This is always sunshinejr/danger-js, not sure where it's needed for now, but we need danger/danger-js for getting diff. There are 3 places that use this repo name. Interesting though.
Good news, I think I've fixed it, inline comments are posted, main comment updated, just need to update 27 tests now 😅 (~~probably will do it tomorrow, though~~ of course I did it today 😄)

@orta found the issue, fixed it, fixed tests. Basically this one. When creating a new GithubAPI we were passing a repoSlug that is a PRs repo, not a base repo, thus we couldn't get a diff using the wrong URL. I'm still wondering why other methods did have a good repoSlug... 🤔

orta · 2018-03-31T12:00:50Z

Yeah, the case of different repo is particularly common for my projects as I nearly always do same-repo PRs 👍

orta · 2018-03-31T12:01:07Z

Going to give it one more audit, then I'll get this shipped

orta

It's happening.

Great work @sunshinejr - this is a tonne of work and hard thinking.

🌞 👶

orta · 2018-03-31T14:34:43Z

Heh, this sneaked in an extra root export:

Fixed with a49c379

sunshinejr · 2018-03-31T15:27:35Z

@orta I just figured out what you meant with the emoji and it's awesome 😄

sunshinejr added 18 commits February 25, 2018 00:36

Add file/line options to context violation

121c434

Add fixtures to test validity of file/line results

7236c02

Pass danger DSL to results handler

127fa2d

Add createInlineComment to API & platform

38ba779

Fix executor tests

2f589e2

Add inline comment when file/line provided

379824d

Add chunks to GitDSL

32ca4fa

Move logic for inline comments to platforms

333fa3b

Calculate position for inline comment in a platform

ca53349

Markdown as Violation as well

77bfe7a

Better Promises & test fixes

8057059

DangerResults updates & tests

f155b46

Fix for dts creator to skip _tests directory

13d7268

Inline comments returning results test

e7a3191

GithubAPI postInlinePRComment tests

8e433b6

Merge remote-tracking branch 'original/azz-bitbucket-server' into fil…

57a5db5

…e_line_api # Conflicts: # source/platforms/GitHub.ts # source/runner/Executor.ts

Fix Bitbucket tests & platform conformation

438c2e2

Some code cleanup

26ec065

sunshinejr mentioned this pull request Mar 4, 2018

Inline mode danger/swift#56

Merged

2 tasks

Fix fixtures

b6f9054

orta reviewed Mar 5, 2018

View reviewed changes

tivac mentioned this pull request Mar 6, 2018

Support inline comments #77

Closed

sunshinejr added 2 commits March 6, 2018 17:24

Improve inline comment message

2b32cdb

More comments around functions & enforce both file and line for inlin…

37dfc32

…e violation

Add BitbucketServer inline comment template as well

4c44daa

sunshinejr changed the base branch from azz-bitbucket-server to master March 15, 2018 14:10

sunshinejr added 6 commits March 16, 2018 23:12

API & platform & test for getting/deleting inline comments

c9c3d52

First version of updating inline comments

26dcf50

Test for updating/creating inline comments

d3eadca

Merge remote-tracking branch 'original/master' into file_line_api

c13ecb7

Delete inline comments handling

1c38bb1

Refactor chunks into StructuredDiff

d2b2315

sunshinejr changed the title ~~[WIP] Inline mode~~ Inline mode. Mar 18, 2018

orta approved these changes Mar 25, 2018

View reviewed changes

orta added 4 commits March 25, 2018 20:51

Adds changelog + some light docs

484671d

Merge master

73e49bd

Pass the danger ID along

674610b

Test out the inline on danger

b1ce78c

sunshinejr and others added 3 commits March 27, 2018 23:21

Update repo slug for GithubAPI to be a base instead of pr

62ad270

Add logging for inline comments

5fc6d66

Remove the testing inline messages

1499ed6

orta added 2 commits March 31, 2018 08:05

Convert console.logs to debug

dd7ed3b

Remove some console logs

8b72d0f

orta approved these changes Mar 31, 2018

View reviewed changes

orta merged commit 0c7e7d7 into danger:master Mar 31, 2018

sunshinejr deleted the file_line_api branch March 31, 2018 15:26

sunshinejr mentioned this pull request Mar 31, 2018

[BitbucketServer] Add inline mode. #549

Closed

Inline mode. #529

Inline mode. #529

Conversation

sunshinejr commented Mar 4, 2018 • edited Loading

Todo:

Choose a reason for hiding this comment

orta left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sunshinejr Mar 6, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

orta Mar 5, 2018 • edited Loading

Choose a reason for hiding this comment

sunshinejr commented Mar 6, 2018 • edited Loading

orta commented Mar 6, 2018

orta commented Mar 6, 2018

sunshinejr commented Mar 6, 2018 • edited Loading

sunshinejr commented Mar 18, 2018 • edited Loading

orta commented Mar 20, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

orta commented Mar 26, 2018 • edited Loading

sunshinejr commented Mar 27, 2018 • edited Loading

orta commented Mar 31, 2018

orta commented Mar 31, 2018

orta left a comment

Choose a reason for hiding this comment

orta commented Mar 31, 2018 • edited Loading

sunshinejr commented Mar 31, 2018

sunshinejr commented Mar 4, 2018 •

edited

Loading

sunshinejr Mar 6, 2018 •

edited

Loading

orta Mar 5, 2018 •

edited

Loading

sunshinejr commented Mar 6, 2018 •

edited

Loading

sunshinejr commented Mar 6, 2018 •

edited

Loading

sunshinejr commented Mar 18, 2018 •

edited

Loading

orta commented Mar 26, 2018 •

edited

Loading

sunshinejr commented Mar 27, 2018 •

edited

Loading

orta commented Mar 31, 2018 •

edited

Loading