How to auto comment merge requests?

Problem to solve

I am creating a new GitLab repository, and when someone creates a new merge request, I would like for there to be comments that are automatically added. These comments are there to help the reviewer and developer ensure code quality and include things like making sure documentation is updated based on the merge request and discussion about whether unit tests may be needed for this new functionality.

Steps to reproduce

There are no steps to reproduce, but I believe I am looking for something similar to what this post is asking for on BitBucket.

Versions

Please select whether options apply, and add the version information.

• Self-managed
• GitLab.com SaaS

Hi,

Have you considered using REST API? You could use it and make a little script that you execute in a CI/CD job when MR is created.

Thanks yeah! I was hoping for a cleaner solution, but after some time I think I got what I need. For future reference, this is what I added as a pipeline in my Gitlab project, where I created a CI variable called CI_AUTOCOMMENTER_API_KEY

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'

auto-comment:
  script:
    - echo "This job runs in merge request pipelines"
    # Here are the comments that will always be added
    - DOCUMENTATION="Did you update the corresponding documentation?"
    # Here we parse them into URL
    - DOCUMENTATION_PARSED=$(echo $DOCUMENTATION | sed 's/ /%20/g')
    # And finally we post them on your merge request!
    - 'curl --request POST --header "PRIVATE-TOKEN: $CI_AUTOCOMMENTER_API_KEY" "https://gitlab.com/api/v4/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/notes?body=$DOCUMENTATION_PARSED"'

@paula.kokic actually my solution, I have now realized, is not ideal. Every time someone makes a new commit to the merge request, the comments are repeated. Is there a way to check if the pipeline has run for this merge request and only running it when the merge request is created?

Otherwise the only other way I can see of doing this is using the API to manually check what comments have been made on the PR, and if they have to not make any more. But that sounds less than ideal…

Hmm, unfortunately, GitLab does not have such an event (purely “merge request created”) - MR pipelines are always executed from the moment on an MR exist and for every new pushed commit (same as branches). Therefore, I personally don’t see an easy way of doing this… just like you said, being very creative and making some manual logic around API.

However, I am trying to solve somewhat the same problem as you (To have a list of checkpoints to do before merging) And I have made it as simple as possible → I edited the MR description template and added a checklist. Of course, this is not really blocking anyone to merge without doing everything, but it’s at least a reminder.

Another option you can have a look at (but only if you have Premium/Ultimate) is Approval Rules for MR. You can have a dedicated person for every rule/check. The issue with this one is (the reason I don’t do it) is that if you have one person approving many checks, upon her/his approval, ALL the rules are immediately approved… which was not really working for us. There is an open issue to add support for this: Allow specifying rule when approving merge requests (#36485) · Issues · GitLab.org / GitLab · GitLab

I know I’ve pushed the topic in another direction now, but perhaps this gives you maybe a wider perspective on other approaches to solve the same problem

Good luck!

@pfrances Another quick workaround/solution to your problem would be to check the notes before posting a new comment again.

Something like:

# And finally we post them on your merge request, if it does not already exist.
- 'curl --header "PRIVATE-TOKEN: $CI_AUTOCOMMENTER_API_KEY" "https://gitlab.com/api/v4/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/notes" | grep $DOCUMENTATION || curl --request POST --header "PRIVATE-TOKEN: $CI_AUTOCOMMENTER_API_KEY" "https://gitlab.com/api/v4/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/notes?body=$DOCUMENTATION_PARSED"'

Hmmm I see. For some reason the grep command portion is not quite working for me. I think I will need to use something more akin to jq and a bash script. Thank you for pointing me in the right direction though

Glad it helped. Not sure why grep is not quite working for you:

➜ DOCUMENTATION="Did you update the corresponding documentation?"; grep -q $DOCUMENTATION test.json; echo $?
0
➜ DOCUMENTATION="No?"; grep -q $DOCUMENTATION test.json; echo $?
1

But as you mentioned, if you have jq available in your pipelines, you may use something like:

➜ DOCUMENTATION="Did you update the corresponding documentation?"; jq --arg doc $DOCUMENTATION -e 'any(.[]; .body == $doc)' test.json; echo $?
true
0
➜ DOCUMENTATION="No?"; jq --arg doc $DOCUMENTATION -e 'any(.[]; .body == $doc)' test.json; echo $?
false
1

Another solution, which might be more reliable, would be to add a label through a pipeline if your comment request succeeds. Like mergecreationsucceded

Then check if $CI_MERGE_REQUEST_LABELS includes your automatically captured labeled before adding the comment, which you can do without having to even start a job. rules: if $CI_MERGE_REQUEST_LABELS ~= /(,|^)mergecreationsucceded(,|$)/

So you could have an entire include: with if that has your “run once on creation” jobs

include: 
 - local: /.gitlab-ci/on_mr_created.gitlab-ci.yml
   rules: 
      - if: $CI_PIPELINE_SOURCE != 'merge_request_event'
        when: never
      - if: $CI_MERGE_REQUEST_LABELS !~ /(,|^)mergecreationsucceded(,|$)/

You might want to then use needs so that these jobs are all independent of the rest of your pipeline with a separate DAG of dependencies

PS: I never remember if the regex needs to match the entire string or not, so please test first

And if you really don’t want them to run twice under any circumstance,

• mark them all as non interruptible,
• and give them a resource group of onmergerequest-$CI_COMMIT_REF_SLUG,
• and make each of the jobs also have its own rules: if... check inside it.
• And be careful with on what order you are executing these jobs

Otherwise, some quick cancellation of the pipeline on new commit might cancel previous jobs and make some of them run twice, sometimes even simultaneously.