Dear Checkout team,
I have several repositories with an identical workflow file.
Sadly one of them get
Run git remote update
git remote update
shell: /bin/bash -e {0}
Fetching origin
error: insufficient permission for adding an object to repository database .git/objects
fatal: failed to write object
fatal: unpack-objects failed
error: Could not fetch origin
##[error]Process completed with exit code 1.
How about the following? We can use the options of this checkout action: https://github.com/actions/checkout/blob/master/action.yml
- uses: actions/checkout@v2
with:
repository: 'owner/repo'
Sadly it did not change the error @peaceiris
It seems that rarely the checkout put wrong file permissions into the .git folder
And I don't see a way to workaround it.
It looks like the step \"repo-sync-sodp\" is running in a container. If it is running as root, then git fetch files created as root.
To mitigate you can add a step after \"repo-sync-sodp\" to recursively change file permissions.
- run: |
chmod -R ugo+rwX .
Thank you
I will try it today evening
What just wonder me is that I have 8 repos with exact the same workflow file and just this single one has this bug.
Yes @ericsciple
ls -lha .git in the worflow file shows me
total 60K
drwxr-xr-x 8 runner docker 4.0K Feb 28 21:03 .
drwxr-xr-x 4 runner docker 4.0K Feb 28 21:03 ..
-rw-r--r-- 1 runner docker 249 Feb 28 21:03 FETCH_HEAD
-rw-r--r-- 1 runner docker 40 Feb 28 21:03 HEAD
drwxr-xr-x 2 runner docker 4.0K Feb 28 21:03 branches
-rw-r--r-- 1 root root 555 Feb 28 21:03 config
-rwxr-xr-x 1 runner docker 73 Feb 28 21:03 description
drwxr-xr-x 2 runner docker 4.0K Feb 28 21:03 hooks
-rw-r--r-- 1 runner docker 227 Feb 28 21:03 index
drwxr-xr-x 2 runner docker 4.0K Feb 28 21:03 info
drwxr-xr-x 3 runner docker 4.0K Feb 28 21:03 logs
drwxr-xr-x 82 runner docker 4.0K Feb 28 21:03 objects
-rw-r--r-- 1 root root 46 Feb 28 21:03 packed-refs
drwxr-xr-x 5 runner docker 4.0K Feb 28 21:03 refs
-rw-r--r-- 1 runner docker 41 Feb 28 21:03 shallow
But only this single repository has this weird behaviour.
chmod -R ugo+rwX . results sadly into Operation not permitted.
Is there anything I can do?
Like somehow removing the files in the container?
Or do they already get new generated on every new action run?
But then I don't understand why this weird bug (only in this single repo) persist.
oh you might need to sudo chmod -R ugo+rwX .
error: insufficient permission for adding an object to repository database .git/objects
My guess is the step \"repo-sync-sodp\" created one of the git object directories - e.g. .git/objects/ab - and the next step tried to write to the same folder?
Thank you, that did fix his special/rare bug :)
Hmmm, but shouldn't it then happen in every repo and modify the entire .git folder?
It is repo-sync/github-sync@v2 which simply reset my own branches with the ones in the upstream fork (which forces me to use a branch with a special name not existing in the upstream repo) to stay in sync for easy rebasing of my own fork changes.
But again, thank you for fixing it and saving me from the email every 15 minutes. :)
Glad to hear :)
The other repos might have enough objects initially that all .git/objects/__ folders are created during checkout (i.e. .git/objects/00/ through .git/objects/ff/.
If you run ls -la .git/objects i'm guessing only a subset have a different owner or different permissions (due to creation during \"repo-sync-sodp\")
i'm just guessing but error message sounds something like that 馃し鈥嶁檪
Most helpful comment
It looks like the step \"repo-sync-sodp\" is running in a container. If it is running as root, then
git fetchfiles created as root.To mitigate you can add a step after \"repo-sync-sodp\" to recursively change file permissions.