Add support for multiline review comments

[maximevw]

Description

When creating a new review or adding comments to an existing review, we can currently only add single line comments. This pull request adds support for single and multi-line comments using line and start_line attributes.

See: https://docs.github.com/en/rest/pulls/comments?apiVersion=2022-11-28#create-a-review-comment-for-a-pull-request and https://docs.github.com/en/rest/pulls/reviews?apiVersion=2022-11-28#create-a-review-for-a-pull-request

I already prepared some tests for this and if you provide access to the hub4j-test-org, I will be able to finalize them. I also successfully tested these changes on a personal project.

This will solve https://github.com/hub4j/github-api/issues/1645

Before submitting a PR:

• [x] Changes must not break binary backwards compatibility. If you are unclear on how to make the change you think is needed while maintaining backward compatibility, CONTRIBUTING.md for details.
• [x] Add JavaDocs and other comments explaining the behavior.
• [x] When adding or updating methods that fetch entities, add @link JavaDoc entries to the relevant documentation on https://docs.github.com/en/rest .
• [x] Add tests that cover any added or changed code. This generally requires capturing snapshot test data. See CONTRIBUTING.md for details.
• [x] Run mvn -D enable-ci clean install site locally. If this command doesn't succeed, your change will not pass CI.
• [x] Push your changes to a branch other than main. You will create your PR from that branch.

When creating a PR:

• [x] Fill in the "Description" above with clear summary of the changes. This includes:
  • [x] If this PR fixes one or more issues, include "Fixes #" lines for each issue.
  • [x] Provide links to relevant documentation on https://docs.github.com/en/rest where possible. If not including links, explain why not.
• [x] All lines of new code should be covered by tests as reported by code coverage. Any lines that are not covered must have PR comments explaining why they cannot be covered. For example, "Reaching this particular exception is hard and is not a particular common scenario."
• [x] Enable "Allow edits from maintainers".

[maximevw]

@bitwiseman Would it be possible to give me access to hub4j-test-org in order to finalize this PR by generating test data?

[bitwiseman]

@maximevw
Sending invite now.

[maximevw]

Hello @bitwiseman,

I updated the tests to finalize this PR. I also added these classes to coverage exceptions, as it was already done for org.kohsuke.github.GHPullRequestReviewBuilder.DraftReviewComment:

• org.kohsuke.github.GHPullRequestReviewBuilder.MultilineDraftReviewComment
• org.kohsuke.github.GHPullRequestReviewBuilder.SingleLineDraftReviewComment

As it is the same principle, and it does not seem really relevant to write specific tests to cover simple getters in very basic POJOs, I preferred to skip the coverage of these getters.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 80.94%. Comparing base (e8c6beb) to head (3df01bb). Report is 5 commits behind head on main.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #1833 +/- ## ============================================ + Coverage 80.79% 80.94% +0.15% - Complexity 2417 2429 +12 ============================================ Files 233 234 +1 Lines 7264 7301 +37 Branches 398 398 ============================================ + Hits 5869 5910 +41 + Misses 1148 1145 -3 + Partials 247 246 -1 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[maximevw]

Hello @bitwiseman

Regarding the failed coverage test on the changes, as stated in my previous comment, it's only getters and it's very hard to cover these lines. I think we can ignore these warnings as the rest of the changes are covered.

Codecov Report

Attention: Patch coverage is 78.78788% with 7 lines in your changes missing coverage. Please review.

Project coverage is 81.04%. Comparing base (92112af) to head (28a18ee).

I don't know if you still expect anything else from me regarding this PR.

[bitwiseman]

@maximevw
My apologies, but I made a broad change to the test data files resulting in a bunch of conflicts. I've attempted a merge, but I think some of the test files still need updating.

Re: Coverage: I'd prefer to test the getters. They're not hard to do and we've had bugs show up when they weren't. (Side note: we had a glitch in coverage reporting for the past week. I had to fix that before responding to your questions.)

Finally, with the complexity of the API, would it make more sense to have a GHPullRequestCommentBuilder rather than trying to model the behavior via a bunch of ternary operators in the request call? This feels like it could be a bug farm.

[maximevw]

@bitwiseman Thanks for your review, I pushed some changes, as requested:

• Create a GHPullRequestReviewCommentBuilder to avoid too complex operations in the request call method
• Add coverage for uncovered getter methods

[maximevw]

@bitwiseman I pushed the requested modifications and answered to your question regarding the deprecation of GHPullRequestReviewBuilder.comment(String, String, int).

[maximevw]

Thanks @bitwiseman for the last modifications, I was a little hasty when I pushed my changes... 😕