Runner doesn't support Windows Long File Paths

When attempting to clean a build directory with children whose absolute paths are longer than 260 characters on a Windows box, the runner fails to remove the files and subsequently fails the build.

Reason for Issue

Go makes use of the standard Windows filesystem APIs which are limited to 260 character file paths, in order to take advantage of the long path support in newer versions of Windows you need to call the Unicode versions of those API methods, and prefix all paths with \\?\ in order to bypass the path preprocessor (which implements the limitation).

Causes

Tools such as npm which use a nested directory structure to store dependencies can rapidly consume the 260 character limit, unfortunately once it occurs you have to manually intervene as subsequent builds will continue to fail until those files are removed.

Solution

Pull in a library supporting long file paths (like syncthing/internal/osutil) to replace the standard library. Alternatively, manually resolve those paths and pass \\?\ as a prefix on Windows systems (manual resolution is necessary as the Windows path preprocessor will be bypassed, relative paths will not be resolved correctly).

Workaround

You can use git config --system core.longpaths true to enable long file paths support in Git and then set GitLab CI to "Fetch" rather than "Clone" the repository - allowing Git to handle the cleaning of those files. This is counter-intuitive and most people are unlikely to adopt it as a solution, not to mention it doesn't change the original reasons for having a clean-and-clone workflow.

Please let me know if there is any additional information you require from me to help resolve this issue as quickly as possible.