Don't enforce that checkout path must be inside of Github Workspace

[LebedevRI]

Fixes #327, Fixes #197.
And i also hit this.

[LebedevRI]

Ok, i guess there was no test coverage for that restriction.
Let me know if a test should be added.

[rhansen]

I hit this too. Would be great to get this merged.

[billhenn]

Please merge this soon, it's becoming a blocking issue for us to run some Windows builds due to hitting MAX_PATH issues with the default long runner path.

With @LebedevRI's update, and by using a relative path outside of GITHUB_WORKSPACE that moves our checkout folder to a much shorter overall length, we are able to prevent hitting the MAX_PATH issue in some older Win32 apps we need to run. This is very important for us.

[LebedevRI]

@ericsciple @chrispat anyone alive at the helm?

[AraHaan]

Can this also add support for:

Run actions/checkout@v2
  with:
    parent: 'Elskom/Sdk'
    repository: 'Elskom/zlib.managed'
    token: ***
    ssh-strict: true
    persist-credentials: true
    clean: true
    fetch-depth: 1
    lfs: false
    parent-submodules: false # clone parent which has submodules, but do not clone the submodule as repository is set to be the submodule. As such both gets cloned and the submodule gets checked out to the actual change that the runner wants to try to build on.
    submodules: false # true if the submodule in repository has submodules itself though.

So then it fits my needs plus I also wanted to clone outside the workspace on even the github hosted runners too (The place that has higher IO rate and as such faster for everything using IO extensive tasks (like building .NET Core projects and other things) that way build would be way faster.

[billhenn]

Is anyone at GitHub going to consider merging this soon?

[AraHaan]

ikr I feel ignored as well too 😆, but I do feel like this PR needs a little bit more work so that it can also be more friendly to me, currently on my submodule I have to have 2 - actions/checkout@v2 for:

• cloning parent project without submodules.
• cloning the submodule.

Which then results in it failing with sourcelink with permission errors because it cannot read the information under .git when I do it manually.

However if the action done it like what I just posted above 8 mins ago it should theoretically work for me too and help me and other developers using submodules and github actions out a ton too (that hit my same issue like what I posted).

Plus then with a single - actions/checkout@v2 I want to clone my stuff into the path that has overall better IO too than where the workspace path it clones it to...

[chrispat]

Moving the repository outside of the workspace would break any actions that work on the contract that the repository is at that location.

For self-hosted runners you can configure the working directory for the runner to any location you want. So, on windows you could make the working directory as simple as D:\s or you can put it on a faster drive. For the hosted runners we already put the working directory for the runners on the fastest storage for those VMs.

[billhenn]

@chrispat - It's been a few months since I worked on our build actions, but I believe the issue was that the checkout@v2 action refused to check out to folder outside of GITHUB_WORKSPACE, even on self-hosted runners. And due to the GITHUB_WORKSPACE path being very long, we ran into MAX_PATH errors in Windows.

Our specific problem was that our GITHUB_WORKSPACE base folder was like: S:\actions-runner\_work\Really-Long-Repo-Name\Really-Long-Repo-Name and a legacy app we needed to run in our build script (that made numerous subfolders and long filenames) ran into MAX_PATH issues. Whereas when we were in Azure DevOps before, they used a shorter base path like S:\Agent\_work\25\s, so we never had issues.

Are you saying that on self-hosted runners, there IS a way to check out to some shorter file path than GITHUB_WORKSPACE, without the changes made in this PR? If so, I'd appreciate it if you could let us know how. Thanks!

[AraHaan]

Moving the repository outside of the workspace would break any actions that work on the contract that the repository is at that location.

For self-hosted runners you can configure the working directory for the runner to any location you want. So, on windows you could make the working directory as simple as D:\s or you can put it on a faster drive. For the hosted runners we already put the working directory for the runners on the fastest storage for those VMs.

I got to disagree, some actions (like setup-dotnet) do not care where the code is checked out or not since it adds the .NET SDK to the PATH environment variable (and if the user specifies a .NET SDK version that is not on the system it will download the install-script for it and install it).

I personally use actions like setup-dotnet, sonarscan, auto-aprove-action (when CI passes from a specific set of users), and automerge (when approved by specific users with write access) and they do not seem to give a damn where the code is checked out.
Honestly when people change where the clone to, they got to do it at their own risk, and then if they use an action that does care that is on them, but if they do not, why does it mater anyway? (Since the developer would have to pay with failing builds no mater what anyway). Heck without this it fails, sometimes with it could fail heck, in that case why not just symlink from the workspace path to whatever path they want the code checked out then (only for the clone of the parent project)?

So if they want to do this to avoid MAX_PATH and they got actions that care where they are at then simply add this as an param to actions/checkout

  with:
    symlink: true

And then it will make a symlink (on windows it's called a directory junction) at %GITHUB_WORKSPACE%\%REPOSITORYNAME% pointing to where the user told the action to really checkout at.

So yes, with this change and adding an symlink option, it would invalidate the excuse to not do this which is:

• some actions work on the contract that the repository is at that location.

With a symbolic link (which can be a directory itself on non windows systems), or an directory junction (known as this on windows systems) you work around the point you stated above (since the workers are using the latest stable macos, ubuntu, and windows anyway (the windows 10 versions the worker has got to have the mklink command for making directory junctions man I am sure of it).

Not like there is no way to tell the action to basically make a directory junction or symlink based on the OS.

Heck I even own a mac and a windows pc using the absolute latest dev builds on both.

[chrispat]

@billhenn

When configuring the runner you can put the runner binaries wherever on disk you want and then you can pass the --work parameter and give it a completely different location such as d:\s.

[AraHaan]

@billhenn

When configuring the runner you can put the runner binaries wherever on disk you want and then you can pass the --work parameter and give it a completely different location such as d:\s.

What about the issue where it wants to spit them to %GITHUB_WORKSPACE%\%REPOSITORYNAME%\%REPOSITORYNAME% instead of %GITHUB_WORKSPACE%\%REPOSITORYNAME% where that path is empty or does not exist to make it shorter (even on the github hosted runners)?

It's bad I run into the issue on github hosted runners, I do not want to be forced to self host my owner runners btw only to try to bypass the issue at hand only to still have the same issue. I feel like with the right configuration options (if the action was to add them to support them) I stated above we could make it just work for both github hosted runners and every single action that exists btw, and self hosted ones too.

Heck if I knew js as well to edit this action myself to add the options I wanted I would and then submit a pull request for them as well too since I think more options so then the user can configure only what they need is better than getting what we run in to currently...

[billhenn]

Hi @chrispat - Yes, I think I did that kind of thing in an effort back then to help shorten the path. But it only handles the S:\actions-runner portion of my long path example. Then you still end up with the base folder being d:\s\_work\Really-Long-Repo-Name\Really-Long-Repo-Name, right? That helps, but it's still a long path.

And as @AraHaan said, I never understood why it duplicates the repo name in the path. It really should only show up once.

[johnandersen777]

@chrispat I understand what you're saying about the default case, but sometime users want to use the checkout action to clone multiple repos and give different path options, this usage should not be artificially restricted.

[Airn5475]

When will this fix go live? Just tried it in Checkout v3 and it still isn't working.

[Yousif-Mobark]

hello ,
can i for the checkout and apply this on my fork and use mine instead of action/checkout??

is it will work ?

[baparham]

Seems approved but has conflicts. Perhaps @LebedevRI can rebase this and get @pdxjohnny and @Yousif-Mobark to re-approve? It would be great to get this merged in.

edit: Oh, nobody with write access has approved, my mistake.

Ugh.

[Airn5475]

Really bummed that this didn't make the latest release. Can we please get someone with write access to review and approve this for the next release??

[wheelerlaw]

@Airn5475 Doesn't seem likely. GitHub has largely abandoned its open source actions it seems, based on the pretty pathetic engagement with the community.

[mocleiri]

I hit the ARG_MAX limit on ubuntu trying to build a custom user module in micropython. I only had 255 files but due to the path depth it went over the limit. What worked for me was to use the standard checkout and then just move the checked out sources up one level.

      - name: Checkout repository
        uses: actions/checkout@v4
      - name: Run Build
        run: |
          mv * ..
          cd ..
          make