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
feat: build failure message from invalid hunks #90
Conversation
Codecov Report
@@ Coverage Diff @@
## comment-pr #90 +/- ##
=============================================
Coverage ? 86.17%
=============================================
Files ? 22
Lines ? 1938
Branches ? 143
=============================================
Hits ? 1670
Misses ? 267
Partials ? 1 Continue to review full report at Codecov.
|
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.
Thanks for the work!
* @param invalidHunks a map of filename to hunks that are not suggestable | ||
*/ | ||
export function buildErrorMessage(invalidHunks: Map<string, Hunk[]>): string { | ||
if (invalidHunks.size === 0) { |
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.
nit: why return an empty string? if there is no error message to be made there should be no message.
You can make the return type : string | null
to return 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.
I'm not sure how this was going to be used. I'd assume we actually want this check outside this and handle that case in the caller.
I chose to return an empty string to be more confident about types in what's being returned. I could note in the description that we will return empty string for an empty input but 🤷. If you were going to check if the result of this was empty or null, you might as well check that the input is empty before calling this method.
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.
Yup that works
…n pull requests (#105) * feat(patch text to hunk bounds): support regex for patch texts (#83) * fix(patch text to hunk bounds): support regex for patch texts * more comments and more tests * fix(framework-core): core-library get remote patch ranges (#84) * fix(framework-core): given files old content and new content, compute the valid hunks (#86) * fix(framework-core): parse raw changes to ranges * refactor(framework-core): rename modules, functions, & re-org project structure (#89) * fix(framework-core): hunk to patch object (#91) * feat: build failure message from invalid hunks (#90) * test: add failing stub and test for building the failure message * fix: implement message building * fix: use original line numbers in error message * docs: add docstring * docs: add note about empty input returning empty string * feat(framework-core): comment on prs given suggestions (#93) * feat(framework-core): main interface for create review on a pull request (#114) * feat(framework-core): main interface for create review on a pull request * docs: fix typo * nits and typos... * gts lint warning fix * fix(framework-core): combine review comments (#116) * fix(framework-core): collapsing timeline and inline comments into single review * test: fixed imports * added case when there are out of scope suggestions and no valid suggestions * feat(framework-core): return review number and variable renaming (#117) * feat(framework-core): return review number and variable renaming * lint Co-authored-by: Jeff Ching <chingor@google.com> Co-authored-by: Justin Beckwith <justin.beckwith@gmail.com> Co-authored-by: Benjamin E. Coe <bencoe@google.com>
This is a barebones implementation that we can start with to build a message for hunks that do not match the PR diff (so they cannot be suggested via review comments).