[go: up one dir, main page]

Skip to content

Project#lfs_objects include system created objects

LfsObjectProject includes a column specifying the repo type.

This is because we use LFS in the Wiki and Design repositories to store the uploads.

I don't think most developers realise this and can potentially lead to using the scope incorrectly e.g. LFS misconfiguration banner

In this case we checked if any LFS objects exist without a .gitattributes file in the project's repository. As LFS objects can include objects for the wiki and designs this is incorrect.

While coming up with a fix I noticed that we probably use this association incorrectly in other locations. I think it would probably make sense to rename this association to all_lfs_objects and create new associations for each of the repository types e.g.

    has_many :lfs_objects_for_project_repository, -> { where(repository_type: :project).distinct }, through: :lfs_objects_projects

ProjectsHelper#project_permissions_panel_data Which is used here

We export all lfs objects https://gitlab.com/gitlab-org/gitlab/-/blob/ff2d7083e57aaa4deb8eeb3812e1e2c8786eea87/lib/gitlab/import_export/lfs_saver.rb#L21-27

LFS integrity checks all lfs objects https://gitlab.com/gitlab-org/gitlab/-/blob/ff2d7083e57aaa4deb8eeb3812e1e2c8786eea87/lib/gitlab/checks/lfs_integrity.rb#L23-25

Questions

  1. Should we be referencing Wiki and Design repo LFS Objects in these situations?
  2. Can we rename the association so by default project.lfs_objects refers to LFS objects related to the project repository and then create another association to return all_lfs_objects?
  3. Should exports include all lfs objects or just project repository lfs objects?
  4. When we fork, do we copy the LFS objects from the wiki and design repo? Should we be?
Edited by Joe Woodward