My build creates a quite long path, I mean longer than the default 260 characters from windows.
Windows is configured with “long pathname” option so my build is successful locally.
On runner side, first build is successful as well. (Build is running in Win 10 power shell)
On the 2nd build, the runner starts to deletes each file from previous build one after the other, but then fails because the runner fails to delete my long pathname files.
I get this error:
“warning: could not stat path ‘my_long_path/xxx/xxx’: Filename too long
ERROR: Job failed: exit status 1”
My idea is to shorten the path name for each directory, this always works with, but if you just need to let the structure as it or of you have many paths, you can just use the Long Path Tool or Gs RichCopy 360, google both
I’m a bit late to the game on this issue but using GitLab Enterprise Edition 14.4.0.ee, my build is having this long file issue with my build on a Windows 10 powershell runner like @Chris1. I enabled long paths in Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem by setting the Enable Win32 long paths to enabled. I even rebooted my windows vm to no avail. Do I need to use a Long Path tool as mentioned by @lianbogdady ?
Just wondering if the other posters on this issue have a better solution because this is blocking my progress on setting up GitLab. @Juan_Miller @lindsayk @ruicruz
Also running into this, it appears to be that git provides the checkout with its own git config from a template.
Gitlab runner has:
HKLM:/SYSTEM/CurrentControlSet/Control/FileSystem/LongPathsEnabled is set to 1,
core.longpaths is set to true,
I am able to clone the same branch/commit that is failing using the command line as the gitlab runner user,
The problem appears to be that builds/$runner/$conc/$group/$proj.tmp/git-template/config does not specify core.longpaths = true and I don’t see a way to assert it.
I got it working for the moment by just adding core.longpaths to the $project.tmp/git-template/config file and repulling, that seemed to work. But I’ll try adding it to the before script when it falls over next time I flush the caches