GitLab Api - How to check if specific file changes

Is it possible to check by REST API if specific file changes between two commits?

If i know first and last commit id or short id I need to check if specific file changes between this two commits

1 Like

Yes, if you look at the API endpoint for a single MR the response comes with a list of changes in the JSON.

1 Like

So, how to ask API about list of changes in specify MR and then how to link it to the commit.
If I know that I need to check changes let’s say, in commit “abcdefgh” I need to get MR liked to that commit. Then a need to ask about list of changes.

If I GET “api/v4/projects/25/repository/commits/short_commit_id” there isn’t any MR iid :frowning:

No, but you can make another API call to fetch the MRs associated with a commit.

So, I need to find list of commits, then the list of MR associated with commits from this list and then find if in this list of MR there are changes of this specific file?

BTW what is it that you are trying to achieve overall? There may be an easier way than using the API…?

I wrote a script which compares last commits in 2 remotes repositories. If commits are different script pulls from one remote repository and push to another remote repository through local repo. Sometimes in source repository developers are overwriting some configuration files so I need to check if this specific files are overwrite properly that’s is why a need to put in script some kind “is config files overwriting?” step which allows me to check this change before script pushes it to second remote repository

Right, I think I get you.

You could do this as you suggest above, by checking the changes in the last few commits and the MRs they came from. As you say, the API does mean that you have to make several calls to get the information you need.

Let’s say the first two repo’s are repo A and repo B. If the commit at HEAD on repo A is different to the commit at HEAD on repo B, do you always pull from A and push to B, or do you sometimes pull/push the other way around?

If you always push in the same direction, I’d be tempted to run the pull/push regardless of whether the HEAD commits are different, as this would simplify your logic a lot.

You could check whether the config files have changed by checking their timestamps before and after the git pull into the locally cloned repo, and that will tell you whether to push to the second remote. That way, you don’t need to look into the commits themselves.

I’m not sure whether that’s helpful, or whether I’ve misunderstood your situation.

The only other thing I’d say (although you may well have thought about this already) is that it might be simpler to keep the script that does this in VCS and run it as a scheduled pipeline, or at the end of your normal pipeline, rather than running it as a separate service.