Get MR review events in API

General
1

Is there a way to get either:

  1. The date time on which an MR was reviewed, or
  2. The date time at which an MR was taken out of Draft / WIP

from the API?

TIA,

Sarah

2

Hi,

As far as I can see from checking the Gitlab docs just now it doesn’t seem possible from the API alone. Technically, you could configure cron jobs to run regularly and check the results with the previous results and do a diff on it to see what changed. Generally the updated_at field would change, plus perhaps WIP changes from true to false, or other status changes, etc.

So for example, I could set a cron job every one hour (or even every 5 mins), and it would do something like this:

  1. Use the appropriate API call to list the MR’s for the project in question and store this in a file
  2. If when running subsequent times a file already exists, copy this to .old so that we can compare with the new results. Then run the API command and diff the two files. With the results, you could then have this sent to you via email. So something like:
#!/bin/bash
#
# Check merge requests

DATETIME=`date '+%F_%H%M%S'`
FILENAME=/tmp/merge-request-check.json
OLDFILENAME=/tmp/merge-request-check.json.old
DIFFFILENAME=/tmp/merge-request-$DATETIME.diff
URL=https://mygitlabinstance.example.com/api/v4/projects/xx/merge_requests

# If the file exists, copy to old
if [ -f "$FILENAME" ]
then
  cp $FILENAME $OLDFILENAME
fi

# Run the API request
curl --headers "PRIVATE-TOKEN: xxxxx" $URL --output $FILENAME

# Compare results
diff $FILENAME $OLDFILENAME > $DIFFFILENAME

replace the URL in the above as I’ve not put a completely accurate URL, just wanted to put something so that the script was understandable. The outputted diff file you can then easily send to yourself via email. You can even put a date/time stamp in the filename, to store multiple diff files in the event of a large amount of changes, so that you are not constantly overwriting the same diff file like I did above in the script variables.

Maybe not ideal, but a possibility.

3

That’s a nice hack, @iwalker but there’s always the possibility that the events you want to record will happen faster than the cron job allows (for example an MR might change assignee, then change back between cron jobs).

I had also thought about tracking comments (notes) but a discussion can happen for many reasons that wouldn’t really count as code review.

This issue will help, but I haven’t found any others that are relevant yet.

4

Yes not ideal, minimum amount of time a cron can run is 1 minute, so all depends how quick someone is, but generally you can diff to see all the changes each minute, or every 5 minutes, or whatever. Would be ideal to have the info in the API calls, unfortunately it’s not there. You could always open a feature request with Gitlab to be implemented for the future.

1 Like