Problem: message() API generates table comment instead of line-specific comment in GitLab MR

[723683592]

Environment Setup:
DangerJS version: 11.3.1
GitLab Runner version: 14.6.0
Node.js version: 14.17.4
Access token permissions: api, read_api, read_repository

Code Snippet:
message(comment.comment, { file: comment.file, line: comment.line, });

Expected Behavior:
I expect this code to add a line-specific comment to the specified file (comment.file) and line number (comment.line) in the merge request (MR).

Actual Behavior:
Instead, it generates a general table comment at the MR level (not linked to the specific file/line).

Questions:
1.Does the message() API in DangerJS v11.3.1 support line-specific comments for GitLab MRs?
2.Are there additional configurations or permissions (beyond api/read_repository) required for line-specific commenting?

[fbartho]

I’m not sure. I don’t use gitlab, but here are some pointers

If you compare this file:

danger-js/source/platforms/gitlab/GitLabAPI.ts

Line 179 in bdccecb

createMergeRequestNote = async (body: string): Promise<Types.MergeRequestNoteSchema> => {

to this file: https://github.com/danger/danger-js/blob/bdccecb77e0144055fbaea9224f10cf8b1229b68/source/platforms/github/GitHubAPI.ts#L322C3-L322C31

You’ll see a bunch of notable differences, including the distinction between a “pull request comment” and an “inline pull request comment”.
Inline PR Comments take a file-path and a line number.

Related:

danger-js/source/platforms/github/comms/issueCommenter.ts

Line 84 in bdccecb

createInlineComment: (git: GitDSL, comment: string, path: string, line: number): Promise<any> => {

So that’s how GitHub (and some other providers) choose to implement line-level commenting. I’m not sure if the underlying GitLab API supports this type of commenting, but it might be this documentation page: https://docs.gitlab.com/user/discussions/#add-a-comment-to-a-merge-request-diff

Hopefully this is a pointer to how to figure out the answer to your questions. I encourage you to submit a documentation update if you find things that should be documented under the GitLab docs, or if you want to submit a feature request, and then a PR that’s a path forwards as well. Other GitLab users will have to review that PR, however.