You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is not so much a bug per se, but a suggested improvement to work around Windows long path limitations.
Despite app-specific workarounds like git longpaths, and despite Windows kind of supporting long paths for a while (and this being enabled in the runner image), there are still some apps that'll break in various ways with long (>260 character) paths. Thus, every letter counts, especially since the repository name is also added to the path, twice. My suggestion is to make the working directory's path under Windows as short as possible.
Now, today long paths shouldn't be an issue for any app out of the box, but decades of the path limitation being in place caused the ecosystem to also rely on it.
Platforms affected
Azure DevOps
GitHub Actions - Standard Runners
GitHub Actions - Larger Runners
Runner images affected
Ubuntu 18.04
Ubuntu 20.04
Ubuntu 22.04
macOS 10.15
macOS 11
macOS 12
Windows Server 2019
Windows Server 2022
Image version and build link
20221002.2
Is it regression?
No
Expected behavior
The working directory has a path as short as possible, like D:\a.
Actual behavior
The working directory's path includes the repository's name, twice, making it potentially really long.
This is a real pain if you have a repository name like https://github.com/Lombiq/Open-Source-Orchard-Core-Extensions. Here, the working directory will be D:\a\Open-Source-Orchard-Core-Extensions\Open-Source-Orchard-Core-Extensions (or under the C drive on larger runners). This leaves us with 183 characters to work with, to stay on the safe side of the 260-character limit. After our prior tests, it seems that pretty much the only option is changing the repo name (what we'd like to avoid).
Repro steps
This is not specific to one build or app. Two examples that I've bumped into:
Git checkout failing. Can be worked around with git longpaths.
SQLite operations failing from under .NET with "SQLite Error 14: 'unable to open database file'".
The text was updated successfully, but these errors were encountered:
Description
This is not so much a bug per se, but a suggested improvement to work around Windows long path limitations.
Despite app-specific workarounds like
git longpaths
, and despite Windows kind of supporting long paths for a while (and this being enabled in the runner image), there are still some apps that'll break in various ways with long (>260 character) paths. Thus, every letter counts, especially since the repository name is also added to the path, twice. My suggestion is to make the working directory's path under Windows as short as possible.Now, today long paths shouldn't be an issue for any app out of the box, but decades of the path limitation being in place caused the ecosystem to also rely on it.
Platforms affected
Runner images affected
Image version and build link
20221002.2
Is it regression?
No
Expected behavior
The working directory has a path as short as possible, like
D:\a
.Actual behavior
The working directory's path includes the repository's name, twice, making it potentially really long.
This is a real pain if you have a repository name like https://github.com/Lombiq/Open-Source-Orchard-Core-Extensions. Here, the working directory will be
D:\a\Open-Source-Orchard-Core-Extensions\Open-Source-Orchard-Core-Extensions
(or under the C drive on larger runners). This leaves us with 183 characters to work with, to stay on the safe side of the 260-character limit. After our prior tests, it seems that pretty much the only option is changing the repo name (what we'd like to avoid).Repro steps
This is not specific to one build or app. Two examples that I've bumped into:
git longpaths
.The text was updated successfully, but these errors were encountered: