Fixes conflicting association name on project namespace
What does this MR do and why?
Currently there seems to be some sort of a conflict with the project
association on project_namespace
model. This was initially detected in specs with following code:
p = create(:project)
p.project_namespace.project == nil # this returns true
However loading the project does not result in the same issue:
p = Project.find(project.id)
p.project_namespace.project == nil # this returns false
This can also be reproduced from a rails console through Projects::CreateService
[1] pry(main)> group = Group.first
[2] pry(main)> params = {
[2] pry(main)* namespace_id: group.id,
[2] pry(main)* name: 'test1'.titleize,
[2] pry(main)* path: 'test1',
[2] pry(main)* description: FFaker::Lorem.sentence,
[2] pry(main)* visibility_level: Gitlab::VisibilityLevel::PRIVATE,
[2] pry(main)* skip_disk_validation: true
[2] pry(main)* }
=> {:namespace_id=>22, :name=>"Test1", :path=>"test1", :description=>"Omnis distinctio omnis nemo sequi atque voluptate non.", :visibility_level=>0, :skip_disk_validation=>true}
[3] pry(main)> project = ::Projects::CreateService.new(User.first, params).execute
[4] pry(main)> project.project_namespace.project
=> nil
With the change:
[156] pry(main)> group = Group.first
[157] pry(main)> params = { namespace_id: group.id, name: 'name15', path: 'name15', visibility_level: Gitlab::VisibilityLevel::PRIVATE }
=> {:namespace_id=>22, :name=>"name15", :path=>"name15", :visibility_level=>0}
[158] pry(main)> project = ::Projects::CreateService.new(User.first, params).execute
[159] pry(main)> project.project_namespace.association(:mirror_project).loaded?
=> true
[160] pry(main)> project.project_namespace.association(:project).loaded?
=> false
[161] pry(main)> project.project_namespace.project
=> nil
[162] pry(main)> project.project_namespace.mirror_project
=> #<Project id: gitlab-org/name15>>
Screenshots or screen recordings
These are strongly recommended to assist reviewers and reduce the time to merge your change.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Alexandru Croitor