fatal: detected dubious ownership in repository at
Closed this issue · 12 comments
I started seeing this error today
It makes no sense, as the actions/checkout added the repo to the safe safe dir list
What could the issue be in this case?
I'm wondering if maybe fixing submodule command escaping caused this (#964). The other recent change to this action was updating @actions/io.
Could you try an older release to see if v3.2.0 caused an issue (v3 is just an alias to the latest)?
uses: actions/checkout@v3.1.0
I'm not able to reproduce this so far. If you could add some logs or a workflow example I can take a look.
Here's a sample job that failed because of that error. The repo is very simple, hopefully it can be helpful to reproduce the issue. I tried v2 and the issue wasn't there for the checkout action but it still was for others like add-and-commit that should work if modifying the git config worked properly (see this job for an example). The workaround I found was to add the directory myself in a separate step before cloning the repo (see this job for an example).
Guys, I don't know why, but after I changed to an order image, the error is gone. My workflow jobs use a container image. I build new images from time to time, every time a new node dependency is updated. I just got an image from 9 days ago and the issue was gone. I really have no clue what is happening because I did not change anything else in the workflow. So, how could an image break this? Would u have any guesses? I can share the dockerfile from the image that works, and the one that has this error.
@cory-miller Im still using @V3 and the issue is gone. Im pretty sure it has nothing to do with this action. The only thing I did was changing my workflows to use a container image that was built a few days ago. But I cant determine exactly why this fixed this issue. I added more details in the issue I created in the actions/runner-images repo.
@cory-miller i tried v2 (latest) and did not work
Finally found the issue. It is caused by a security patch that was released for git in some package managers. If you want a solution, read the other ticket that I linked from the runner's repository.
Mine was caused by installing a few more packages (which suddenly got updated). Getting rid of those dependencies solved my issue.
I think if this is running in a container it needs to be --system and not --global for some reason.
So, inside a container it makes sense why the global git config doesn't exist: it clearly wasn't created by the runner or checkout.
git config --global --list
fatal: unable to read config file '/github/home/.gitconfig': No such file or directory
I'm pretty sure this is a real bug and will open a new issue for it.
FFR: Just use the users option:
actions/runner#2033 (comment)
Still facing a problem when using gh in an action that uses a container. Here is my workflow file: https://github.com/huggingface/check-pr-test-workflows/actions/runs/9096755130/workflow.
Here are the logs: https://github.com/huggingface/check-pr-test-workflows/actions/runs/9096755130/job/25002925621
Any suggestions?
I have tried adding --user and it didn't help.