Use shorter working directory path on Windows runners

[Piedone]

Description

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.

This is not the same as #923 (since that happens under Linux, apparently).

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'".

[interifter]

I have seen several issues opened around this and the related issue with runners, but no traction. How do we get visibility on these issues?

[Piedone]

Any updates perhaps, @cory-miller @takost or anybody else? Not adding the repository name to the checkout directory twice seems like an easy win for me.

[Piedone]

This can also break upload-artifact, see actions/upload-artifact#240.

[TRB7]

Facing same issue with Windows runner, I had to change to Ubuntu...

[interifter]

So, folks, is this actually a problem with actions/checkout?

The underlying mechanics that causes this bizarre pathing issue is actually in https://github.com/actions/runner

It is the one that generates the _PipelineMapping/<owner group>/<repo name>/PipelineFolder.json file that ultimately controls where content gets checked into.

Example:

{
  "repositoryName": "actions/checkout",
  "pipelineDirectory": "checkout",
  "workspaceDirectory": "checkout\\checkout",
  "repositories": {
    "actions/checkout": {
      "repositoryPath": "checkout\\checkout",
      "lastRunOn": "11/02/2023 11:50:28 -07:00"
    }
  },
  "lastRunOn": "01/26/2024 15:36:35 -08:00"
}

See the data model here: https://github.com/actions/runner/blob/main/src/Runner.Worker/TrackingConfig.cs#L20

[Piedone]

You might be onto something! However, the runner repo points us to the community discussions with such requests. But I had bad experiences with my product feedbacks there, mostly not getting any replies. However, being the optimist I am, I opened this there too: https://github.com/orgs/community/discussions/118587.

[interifter]

Related: #197

Related: actions/runner#1676

For 1676, I actually commented on it (and forgot) My bad...

[Piedone]

Ah, thanks!