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

[pvanloo]

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] (https://github.com/actions/checkout/issues/197#issuecomment-697321125) 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
(...)