Update gitlab.yml.example

What does this MR do?

Explains the problem instead of Yelling.

The relevant part that fails is in gitlab-shell: https://gitlab.com/gitlab-org/gitlab-shell/blob/v3.6.6/hooks/post-receive#L8

Are there points in the code the reviewer needs to double check?

No

Why was this MR needed?

It's better explain the problem than YELL.

Screenshots (if relevant)

Does this MR meet the acceptance criteria?

• CHANGELOG entry added
• Documentation created/updated
• API support added
• Tests
  • Added for this feature/bug
  • All builds are passing
• Conform by the merge request performance guides
• Conform by the style guides
• Branch has no merge conflicts with master (if it does - rebase it please)
• Squashed related commits together

What are the relevant issue numbers?

Added 1 commit:

• afc465d9 - Update gitlab.yml.example

Compare with previous version

This is nice. I always want to know why. If that's the only offending line, is there a way to fix it, I am wondering? For example, before setting the path, we check if the path is actually leading to a symlink, then do File.expand_path(File.readlink(storage_path))? Or I guess this might not be worth the complexity?

Added ~164274 label

@godfat you can not do that, it's impossible to know whether you entered the directory via actual path or via some symlink.

what gitlab-shell does is this:

• git does chdir /repositories/repo.git
• gitlab-shell does pwd

so if /repositories/repo.git is symlink to /mnt/repositories/repo.git, then even you did "cd /repositories/repo.git", the "pwd" will print real path: "/mnt/repositories/repo.git", and if you test this in bash, then bash "emulates" you the "virtual path" (remembers previous chdir calls), run /bin/pwd, not bash builtin pwd to see the difference.

hope you understand, it's very hard to explain this.

in my system, i hacked this this way:

repo_path = ENV.delete('GITLAB_REPO') || Dir.pwd

and i set GITLAB_REPO before calling hooks from gitlab-shell

Thanks @glensc!

Milestone changed to %8.14

Reassigned to @rymai

Status changed to merged

Mentioned in commit 1537b1d3

@glensc Yeah I think I understand it, but I was talking the other way around, without touching gitlab-shell. Instead, we check if it's a symlink when reading the configuration. Something like:

Gitlab.config.repositories.storages.map! do |path|
  File.expand_path(
    if File.symlink?(path) then File.readlink(path) else path end)
end

So we're still using the absolute real path rather than symlink, just that the configuration could take symlink there. But I am not sure if this is worth the effort.

@godfat your example assumes last path component is symlink, but no path component can be symlink, so that solution works for one specific case, not all cases.

[/tmp] ➔ find dir1 -ls
444159750      0 drwxrwxr-x   3  glen     glen           60 nov    3 20:19 dir1
444159751      0 drwxrwxr-x   3  glen     glen           80 nov    3 20:20 dir1/dir2
444164775      0 lrwxrwxrwx   1  glen     glen            4 nov    3 20:20 dir1/dir2/dir4 -> dir3
444159752      0 drwxrwxr-x   3  glen     glen           60 nov    3 20:20 dir1/dir2/dir3
444166548      0 drwxrwxr-x   2  glen     glen           40 nov    3 20:20 dir1/dir2/dir3/dir5
[/tmp] ➔ test -L dir1/dir2/dir4/dir5 && echo is link
[/tmp] ➔ readlink -f dir1/dir2/dir4/dir5 
/tmp/dir1/dir2/dir3/dir5
[/tmp] ➔ 

anyway, i have't looked gitlab-ce part, so can't comment more.

@glensc Good point! I never thought of that. I guess this clearly shows that this is not worth the effort to work on. Thanks for the explanation!