[go: up one dir, main page]
Skip to content

Ambiguous behaviour of integration of LFS in REST API

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

gitlab's API does not handle LFS in the same way when creating or updating large files.

On creation, the backend computes sends the file to LFS subsystem and replace it with its LFS pointer value (see https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/files/multi_service.rb#L20)

On update, it doesn't.

Using GitLab Community Edition 14.2.1

Steps to reproduce

You need a client that is aware of LFS and that pushes to the LFS sub-system the file content and commits the computed pointer to GITLAB using gitlab's REST api.

  1. Push the huge file my-huge-file to LFS
  2. Compute the pointer of the huge file
  3. Update the .gitattributes file in order to tell that the file my-huge-file is handled by LFS (filter=lfs)
  4. Commit using REST API, the pointer as my-huge-file and .gitattributes
  5. Now, when you pull you get a pointer to the pointer in LFS
  6. Commit using REST API, any garbage data as my-huge-file
  7. Now, when you pull you get the garbage
  8. Commit using REST API, the first pointer as my-huge-file
  9. Now, when you pull you get the expected file

What is the expected correct behavior?

The backend must have only one policy. Wich one? I don't now, it depends on the current implementation of other components of gitlab. But, on my opinion, it would be cool if the backend does all the job.

Results of GitLab environment info

Using GitLab Community Edition 14.2.1

Possible fixes

Remove the test line 20 (see https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/files/multi_service.rb#L20)

Edited by 🤖 GitLab Bot 🤖