checkout: Unable to clone outside of GITHUB_WORKSPACE directory
Hi Guys. I have a directory where the source code is located. I’m trying to create an action to:
- Pull the last code on that directory (example /home/my-code/src)
- Run npm install on that directory
- 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
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 30
- Comments: 46 (1 by maintainers)
Commits related to this issue
- Don't enforce that checkout path must be inside of Github Workspace Fixes #327, Fixes #197. And i also hit this. — committed to LebedevRI/checkout by LebedevRI 4 years ago
- Don't enforce that checkout path must be inside of Github Workspace Fixes #327, Fixes #197. And i also hit this. — committed to LebedevRI/checkout by LebedevRI 4 years ago
- Don't enforce that checkout path must be inside of Github Workspace Fixes #327, Fixes #197. And i also hit this. — committed to LebedevRI/checkout by LebedevRI 4 years ago
- Works around limitation of actions/checkout. The checkout action disallows cloning a repo anywhere outside GITHUB_WORKSPACE which, in linux, translates into /home/runner/work/Mojee/Mojee. If I just ... — committed to fabriciomurta/Mojee by fabriciomurta 3 years ago
- feat(TEST): Make paths relative $GITHUB_WORKSPACE cannot be changed, so there is not control over where the repo is cloned. So absolute paths don't work. reference: https://github.com/actions/checko... — committed to mattprompt/sub-etha-tinycomms by mattprompt 3 years ago
- Add new working directory path — committed to imcs-compsim/pvutils by eulovi a year ago
- COMP: Workaround actions/checkout limitation This addresses the following error: Error: Repository path '/home/runner/work/SlicerDMRI/Slicer' is not under '/home/runner/work/SlicerDMRI/SlicerDMRI'... — committed to jcfr/SlicerDMRI by jcfr a year ago
- COMP: Workaround actions/checkout limitation This addresses the following error: Error: Repository path '/home/runner/work/SlicerDMRI/Slicer' is not under '/home/runner/work/SlicerDMRI/SlicerDMRI'... — committed to jcfr/SlicerDMRI by jcfr a year ago
- Work around actions/checkout#197 — committed to sass/sass-spec by nex3 a year ago
- Work around actions/checkout#197 — committed to sass/sass-spec by nex3 a year ago
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:
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.)
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 forrun
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)
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 manualgit 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.
I’m using the version I removed that validation, like I said in the comment above