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.
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.
1 Like
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!
1 Like
@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"'
2 Likes
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.