checkout: Unable to clone outside of GITHUB_WORKSPACE directory

This is important functionality for our builds because we have long repository names. We’re getting paths like: D:\a\VeryLongRepositoryNameAAAAAAAAAAAAAAAAAAA\VeryLongRepositoryNameAAAAAAAAAAAAAAAAAAAA\src\ALongProjectNameBBBBBBBBBBBBBBBB\ALongProjectNameBBBBBBBBBBBBBBBB.csproj

We’re hitting MAX_PATH on Windows builds. We need to be able to checkout and build in a directory like: D:\a\s\src\ALongProjectName...

In my case I wanted to integrate a repo in a workflow such as ../repo-name would find the other repo. This way I could add the new repo to the workflow yet not break paths in the subsequent steps.

I am going with:

(...)
    path: repo-name-${{ github.run_id }}-${{ github.run_number }}

- run: mv repo-name-${{ github.run_id }}-${{ github.run_number }} ../repo-name
(...)

I have made this PR #1493 exactly for this issue.

We had found this issue because the long GITHUB_WORKSPACE base paths caused us to run into MAX_PATH issues on our Windows build server. We never had this issue with Azure DevOps since their base path is about one-third the length.

By using the changes in #388 by @LebedevRI, we were able to work around the issue and use GitHub Actions for our workflow. We need those changes implemented officially in the Checkout action though and would appreciate those changes being merged soon.

For now, I removed that validation and it worked!

https://github.com/rodrigorodriguescosta/checkout/commit/eb8d76c670114822594a2c25cde341adfbab5d60

I’d like to use oficial release without that validation!

So we’re running a self-hosted runner, so the runner is in /etc and we don’t want our code to be on that location. @jsg2021

Thanks @ericsciple . The limitation with path parameter is as you said, it needs to be under GITHUB_WORKSPACE. Tried with absolute paths and …/…/{blabla} but error hapenned.

Please add a working-directory input variable the way the Run action does so that we can change the base dir.

On some docker images we cannot clone into the default location due to user-level permissions and have to set the working directory to the home directory.

Right now actions/checkout doesn’t support this use case of running in containers that only allow writing to specific paths.

For now I’ve worked around this like so:

https://github.com/HariSekhon/GitHub-Actions/blob/master/.github/workflows/jenkinsfile.yaml

I wish we could tell checkout that when cloning an subproject (within a different repository) to instead clone the parent one recursively just so that way it can basically properly build the subproject (especially when it depends on files from within the parent project and imports them and expects those files to exist when building.

Just stumbled upon this issue. What an arbitrary limitation. Why? Fortunately I don’t have a problem with long paths, in this specific instance.

(btw, how come 40 year of development wasn’t enough to properly support the concept of directories? Windows is hopeless. It would have died long ago if they didn’t had it installed in schools. Which hopefully soon will get banned.)

As @rodrigorodriguescosta test confirmed that extra validation prevents us from cloning directly to the correct location. Any change to get this fixed?

I’m using the version I removed that validation, like I said in the comment above

     - name: Checkout 
        uses: rodrigorodriguescosta/checkout@main
        continue-on-error: true
        with:
          repository: youruser/repository
          token: ${{ secrets.ACCESS_TOKEN }}
          ref: ${{ env.BRANCH_NAME }}
          path: ../comps

Wait so we can use that to clone a private repo in the build pipelines that is a dependecy within a public github action of a public repository?

this is the forked of this project, I just removed that validation, you can use in any project, just change the url of the action which is that I posted above, I’m using it in my private project

Perhaps you could create a symlink from the github workspace folder (_work by default) to another location.

This won’t help long repository names though…

That’s possible indeed, I mostly wanted to report this additional limitation/issue with the Action as is

So I can’t clone an extra repo in the parent of the current path (because of the problem above), but I also can’t have both repositories in the same path because working-directory only works for run steps (and I won’t be able to run other actions on a sub-directory).

This is absolutely fked up and I just can’t understand how this issue is open since 3 years without any viable solution.

I find this ridiculous, compared to GitLab and Bitbucket pipelines, GitHub actions are insanely complicated and miss the very basics of shell scripting. (I’m not saying this lightly - Bitbucket pipelines, which I’m forced to use at work, are very limited in many ways)

I wonder if passing GITHUB_WORKSPACE as env would tricky it to use a different location.

You can’t set any environment variable prefixed with GITHUB for safety - I’ve tried before, it just ignores it. This is actually quite annoying when you actually want to set a GITHUB_TOKEN… (for which I use the workaround GH_TOKEN, which luckily just so happens to work with the GitHub CLI).

I’ve worked around GITHUB_WORKSPACE by doing a manual git clone using commands since this action hardly saves any code anyway, which you can see in the link I posted above to my public GitHub Actions repository.

If anyone has a better solution I’d love to hear it. @grbd’s symlink idea is worth a shot too.

Otherwise, this action would probably need to relax the restriction on cloning outside GITHUB_WORKSPACE.

Another use case:

I need to pull a different repository into the worker and take action on it separate from the repository running the worker. I want to put this second repository inside of RUNNER_TEMP so it gets cleaned up after the job is done.

As @rodrigorodriguescosta test confirmed that extra validation prevents us from cloning directly to the correct location. Any change to get this fixed?

I’m using the version I removed that validation, like I said in the comment above

     - name: Checkout 
        uses: rodrigorodriguescosta/checkout@main
        continue-on-error: true
        with:
          repository: youruser/repository
          token: ${{ secrets.ACCESS_TOKEN }}
          ref: ${{ env.BRANCH_NAME }}
          path: ../comps