Unable to clone outside of GITHUB_WORKSPACE directory

[eabuslaiman30]

Hi Guys. I have a directory where the source code is located. I'm trying to create an action to:

1. Pull the last code on that directory (example /home/my-code/src)
2. Run npm install on that directory
3. Run npm run build on that directory.

Anyway, I set the env var $GITHUB_WORKSPACE into my yml file, but it seems to be not respecting the directory where the code is cloned / pulled in.

My script:

name: Development Deploy

on:
  push:
    branches: [ develop ]

jobs:
  build:

    runs-on: self-hosted

    strategy:
      matrix:
        node-version: [10.10.0]
    steps:
      - name: Updating base code from develop
        uses: actions/checkout@v2
        with:
          ref: refs/heads/develop
          GITHUB_WORKSPACE: /home/my-code/src

    ... Another steps here

The log says the following:

Added matchers: 'checkout-git'. Problem matchers scan action output for known warning or error strings and report these inline.
Syncing repository: repoowner/reponame
Working directory is '/etc/actions-runner/website/src/reponame'

Is there anyway I can use the existing directory to use the checkout action? I want this to be cloned on /home/my-code/src

Thanks

[jsg2021]

I could be wrong, but I think that's a reserved variable that already has meaning in this system.

[jsg2021]

Why do you need to specify where the code is cloned? This action takes care of that for you.

[ericsciple]

Today the path input is the only way to change the directory where the code is cloned. Also there is a restriction that it must be under GITHUB_WORKSPACE. If you want to get around that limitation, you could add a run step to move or copy the folder - or soft/hard link too i guess but but might unexpected issues later 🤷‍♂

[eabuslaiman30]

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.

[ddrinka]

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

[dukeofphilberg]

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

[AzfaarQureshi]

I was running into the same issue, @ericsciple thanks for the workaround suggestion! :)

do you know if the $GITHUB_WORKSPACE variable can be changed elsewhere?

[gengjiawen]

On windows, too

Run actions/checkout@v2
  with:
    path: C:/nodejs
    repository: gengjiawen/node
    token: ***
    ssh-strict: true
    persist-credentials: true
    clean: true
    fetch-depth: 1
    lfs: false
    submodules: false
  env:
    PYTHON_VERSION: 3.8
    FLAKY_TESTS: dontcare
Error: Repository path 'C:\nodejs' is not under 'D:\a\node\node'

[moelleru]

Hi, running into the same issue. Thanks to @LebedevRI for the fix. But any idea when this fix will be available?

[nitin-jci]

I tried configuring self hosted runner as suggested by @pvanloo in above [comment] (#197 (comment)) and it worked for me.

If someone needs a specific workspace, I would suggest to give a try with self hosted runner and specify your workspace path in work folder configuration.

[billhenn]

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.

[AraHaan]

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.

[AraHaan]

Why do you need to specify where the code is cloned? This action takes care of that for you.

I would like you to take a look at submodules and how some people have them depend on the parent project in order to build the submodules successfully.

Many programmers do that for a reason to help try to reduce maintenance on the code especially when some subprojects might require a ton of work and so makes more sense to do it in a submodule, then when the work is done update the module in the parent repository.

So this is what I think actions/checkout should allow:

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.

[fabriciomurta]

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
(...)

[tanvirstreame]

Looking for a solution soon

[rodrigorodriguescosta]

For now, I removed that validation and it worked!

rodrigorodriguescosta@eb8d76c

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

[asidt]

Thank you @fabriciomurta I had the same case, and your solution #197 (comment) worked like a charm!

[manpreet-agoro]

The problem also complicates if your previous steps used a container to do the work and new step uses base machine, now you have code which is owner by a root in a non-root owned workspace. Any execution which happens on base node fails since the code cannot be cleaned/checked out.

Anyway to disable the "workspace" mapping into the container?

[uuf6429]

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)

[jbaryy708]

I was running into the same issue, @ericsciple thanks for the workaround suggestion! :)

do you know if the $GITHUB_WORKSPACE variable can be changed elsewhere?

Can you help me?

[jbaryy708]

Hi.. I wan the url or workspace can you help me

[ManikantaVenkateshappa]

I found a workaround for this. Our CI build was failing with long path issues. Then I have updated the below file with custom directory paths then it worked like a charm. This works fine as long as same repo is checked out from git action.

First you need to run the workflow, which performs one round of checkout, later you make the below changes.

file: runner-work-area\_PipelineMapping\your-org\repo-name\PipelineFolder.json

Default contents of the file:
{
"repositoryName": "your-org/repo-name",
"pipelineDirectory": "repo-name",
"workspaceDirectory": "repo-name\repo-name",
"repositories": {
"your-org/repo-name": {
"repositoryPath": "repo-name\repo-name",
"lastRunOn": "04/12/2023 16:00:53 +02:00"
}
},
"lastRunOn": "04/12/2023 16:45:29 +02:00"
}

Custom contents of the file: Note the custom directory value
{
"repositoryName": "your-org/repo-name",
"pipelineDirectory": "customDir",
"workspaceDirectory": "customDir",
"repositories": {
"your-org/repo-name": {
"repositoryPath": "customDir",
"lastRunOn": "04/12/2023 16:00:53 +02:00"
}
},
"lastRunOn": "04/12/2023 16:45:29 +02:00"
}

[mefistotelis]

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.)

[cezar-tech]

i have to checkout 2 repos, this also affects me.

[jakoch]

what is the workaround? fetch the branch as zip and extract into outside of workspace folder?

seems mv folder ..

[Hecatron]

what is the workaround? fetch the branch as zip and extract into outside of workspace folder?

I put a workaround further up

One workaround might be to create a symbolic link
So under windows after the checkout for example

      - name: Link working directory
        run: New-Item -Path D:/rust -ItemType SymbolicLink -Value D:/a/rust-build/rust-build

That way a shorter path can be used.
Under Linux it'd be "ln -s" instead

That way you can for example extract things into D:/a/rust-build/rust-build, but then do any compiling via D:/rust as they both point to the same place

[ManikantaVenkateshappa]

what is the workaround? fetch the branch as zip and extract into outside of workspace folder?

Please check if this helps: #197 (comment)

[accodev]

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

[WiehanVanNiekerk]

I'm doing another follow-up on this request regarding PR #1493

[WiehanVanNiekerk]

I'm doing another follow-up on this request regarding PR #1493

@cory-miller, @takost , @luketomlinson

[eXpl0it3r]

If you have a repository name that ends in a dot, you can't use the checkout action on a Windows runner, because the workspace directory is always the repository name, but Windows doesn't allow for directory names with a trailing dot...

For example: M.A.R.S.

[HariSekhon]

@eXpl0it3r why don't you just check out to an explicitly specified directory name like mars?

[eXpl0it3r]

See the issue we're in. I can't clone anywhere else other than the $GITHUB_WORKSPACE which is also the repo name (i.e. M.A.R.S.), which again can't be created on a Windows agent due to the trailing dot.

[HariSekhon]

You may have missed the workaround in my comment further above:

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 you do a git clone in a shell run step you can put it anywhere you want and with any directory name you want as an extra arg to the git clone command.

Or is the problem you're having that the agent fails to spawn properly as it tries to pre-create the $GITHUB_WORKSPACE directory which fails even without using a checkout action?

[eXpl0it3r]

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