-
-
Notifications
You must be signed in to change notification settings - Fork 368
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add convenience info to danger.git.diffForFile
#223
Conversation
source/dsl/GitDSL.ts
Outdated
@@ -64,8 +76,7 @@ export interface GitDSL { | |||
* @param {string} filename the path to the json file | |||
* @param {string[]} diffTypes An array containing: "add", "del" or "normal" - then you can only get these changes | |||
*/ | |||
|
|||
diffForFile(filename: string, diffTypes?: string[]): string | null, | |||
diffForFile(filename: string, diffTypes?: string[]): Promise<TextDiff | null>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
think you can kill diffTypes
in favour of this /cc @alex3165
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we still keep the added
/removed
/normal
changes? They're not really the same as JSONDiff
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't they be the raw string content of all the hunks combined?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes that does make sense. @alex3165 does this satisfy your use-case?
i.e. instead of calling diffForFile('foo.js', ['add'])
, you'd call diffForFile('foo.js').added
which would return the same sort of string.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I honestly am confused about the meaning of normal
in this context -- I think it refers to "contextual" lines (i.e. non-changed lines that sandwich an addition/deletion).
If I'm correct about this, I struggle to see how it'd be useful to have these lines without being combined with added
or removed
.
Maybe we could just provide the raw structuredDiff
from parseDiff
's output as an escape hatch for folks who need finer control.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe then added and removed should be add + normal
and del
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After some thinking, here's what I think would be more useful for most folks:
/** All Text diff values will be this shape */
export interface TextDiff {
/** The value before the PR's applied changes */
before: string
/** The value after the PR's applied changes */
after: string,
/** A string containing the full set of changes */
diff: string,
/** A string containing just the added lines */
added: string,
/** A string containing just the removed lines */
removed: string,
}
This covers all cases except for the odd one where you only want normal
/contextual lines, which seems quite fringe to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that feels 👍 to me
source/platforms/github/GitHubGit.ts
Outdated
removed: changes.filter(({type}: {type: string}) => type === "del"), | ||
normal: changes.filter(({type}: {type: string}) => type === "normal"), | ||
diff: lines.join(os.EOL) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Codecov Report
@@ Coverage Diff @@
## master #223 +/- ##
=======================================
Coverage 68.62% 68.62%
=======================================
Files 34 34
Lines 765 765
Branches 105 104 -1
=======================================
Hits 525 525
Misses 240 240
Continue to review full report at Codecov.
|
source/platforms/github/GitHubGit.ts
Outdated
|
||
// Filter the diffs by type | ||
if (diffTypes && diffTypes.length > 0) { | ||
changes = changes.filter((c: any) => diffTypes.indexOf(c.type) !== -1) | ||
} | ||
|
||
const baseFile = await api.fileContents(filename, pr.base.repo.full_name, pr.base.sha) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: I'm using sha
here instead of ref
, mainly because the example PR used for the fixture seemed to have deleted the original branch.
We may also want to use sha
above in the implementation of JSONPatchForFile
.
@orta Thoughts? Any reason to prefer ref
over sha
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no difference IMO 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sha
may be better incase a potential branch has had new commits since the CI was started, and then when danger runs
Hmm... I must be missing something. The tests are passing on my machine but AppVeyor doesn't seem to like it. 🤷♂️ |
@@ -20,15 +20,19 @@ export const requestWithFixturedContent = async (path: string): Promise<() => Pr | |||
Promise.resolve(readFileSync(`${fixtures}/${path}`, {}).toString()) | |||
) | |||
|
|||
const pullRequestInfoFilename = "github_pr.json" | |||
const masterSHA = JSON.parse(readFileSync(`${fixtures}/${pullRequestInfoFilename}`, {}).toString()).base.sha |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
try using the path API for this string - that might be what's breaking on windows, can't remember its name yet
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could possibly be a bug with Jest's snapshot testing. :-/ Their Windows support is still pretty unstable AFAIK.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought maybe it had something to do with line endings, but that shouldn't be an issue: jestjs/jest#1879
These failing snapshots feel backwards, like it's inverting the before and after |
Yeah, the Jest output doesn't really make sense. It treats every line but the last as different, even though if you copy/paste the terminal output and do a diff after cleaning out the additional |
yeah, must be some invisible characters - can we strip them for the test? |
Yup. Stripping the whitespace seemed to fix the issue. I'll make this more explicit and add a |
👍 Perfect |
I'd wait for @alex3165's response, but otherwise does this look good? |
Yep, everything looks 👍 |
will merge and release EOD tomorrow if we don't hear anything back |
also, I've invited you to the org, as a part of Moya Community Continuity - you're welcome to participate (or not, we're chill) in PRs and help out at a level that works for you. |
Fixes #221
Changes the signature for
danger.git.diffForFile
to the following:TODO
yarn declarations
before
after
added
removed