Do not set perms on an AFS repository path.

If using OpenAFS to store gitlab repositories, i.e. the repository path begins with "/afs/.../", the attempted chowns in the gitlab shell recipe will fail due to some AFS weirdness. Since AFS does not use Unix permissions and occasionally doesn't play nicely with them, the simple solution is to prevent gitlab (or rather chef) from attempting to set ownership and just create the directory.

This means it will be the sysadmin's reponsibility to make sure whatever AFS principal gitlab is running under has the permissions to read and write the repository path. This seems reasonable to me since making gitlab run with a set of AFS/Kerberos permissions requires some other minor modifications anyway.

This change allows gitlab-ctl reconfigure to keep running if the repositories are being stored in AFS (otherwise, it fails due to an internal error when attempting to chown).

We ran into this at our site because we wanted our git VM to store its repositories in AFS (which gets backed up) as opposed to the VM's root disk (which do not). I intend to document the changes that were necessary to get gitlab to run and keep Kerberos tickets (and thus have AFS permissions necessary to read/write outside of AFS), though all I actually had to do was create a service that runs on the machine and every ~interval ensures that the git user has AFS tokens.

Anyway, this fix was the simplest solution to allow gitlab-ctl reconfigure to complete inside of AFS. Once reconfigure worked, gitlab itself just worked once the git user had AFS tokens.

It may be the case that there are other strange filesystems that the chown command will also fail on, but AFS is really easy to check for because the mount point for the AFS root cell is, invariably, /afs.

We can carry this patch locally if you are not interested in merging it, but it would be really nice if we could get it upstream. :)