actions/checkout fails on git repos that use SHA256
actions/checkout@v3 and @v4 fails on git repos that use SHA256 instead of SHA1.
Expected result: checkout works.
Actual result: checkout fails with couldn't find remote ref
Fetching the repository
[38](https://forge.wildeboer.net/JHWOrg/MyTODO/actions/runs/22#jobstep-4-38)
[command]/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +bd7d79ede2060266e3e30c5f233938f82868d4533e06b19588c5ce0cfc072c89:refs/remotes/origin/main
[39](https://forge.wildeboer.net/JHWOrg/MyTODO/actions/runs/22#jobstep-4-39)
fatal: couldn't find remote ref bd7d79ede2060266e3e30c5f233938f82868d4533e06b19588c5ce0cfc072c89
[40](https://forge.wildeboer.net/JHWOrg/MyTODO/actions/runs/22#jobstep-4-40)
The process '/usr/bin/git' failed with exit code 128
[41](https://forge.wildeboer.net/JHWOrg/MyTODO/actions/runs/22#jobstep-4-41)
Waiting 19 seconds before trying again
[42](https://forge.wildeboer.net/JHWOrg/MyTODO/actions/runs/22#jobstep-4-42)
[command]/usr/bin/git -c protocol.version=2 fetch --no-tags --prune --progress --no-recurse-submodules --depth=1 origin +bd7d79ede2060266e3e30c5f233938f82868d4533e06b19588c5ce0cfc072c89:refs/remotes/origin/main
[43](https://forge.wildeboer.net/JHWOrg/MyTODO/actions/runs/22#jobstep-4-43)
fatal: couldn't find remote ref bd7d79ede2060266e3e30c5f233938f82868d4533e06b19588c5ce0cfc072c89
[44](https://forge.wildeboer.net/JHWOrg/MyTODO/actions/runs/22#jobstep-4-44)
The process '/usr/bin/git' failed with exit code 128
The image I use (ghcr.io/catthehacker/ubuntu:act-latest) has git version 2.46.0 which supports SHA256 based repos, so it seems that is not where the problem is coming from.
Is there any updates on this issue?
this is still relevant.
Any updates on this? I see https://github.com/actions/checkout/pull/1945 has approval but am wondering if there are any blockers to merging.
Thanks so much yangskyboxlabs for putting together a fix!
#1945 is still waiting for a response from a codeowner.
Still no news?
See my comment on #1945 to try to pick up and progress the conversation a bit. https://github.com/actions/checkout/pull/1945#issuecomment-3340336266
I believe this also stops you from you from using repo-actions hosted in sha256 repositories.
The error when using sha-256 is so vague, that only because I happen to remember that I created my repo with sha-256 months before that that might be a problem. But I thought that sha256 was basic functionality these days…
I now use the @yangskyboxlabs fork of their PR directly in my checkout step:
steps:
- name: Checkout Repository (sha-256 patch)
uses: https://github.com/yangskyboxlabs/action-checkout@b9de40a2281eb217887b8290be4254823d67a20b # Same as actions/checkout@v4, but with sha256
with:
object-format: sha256
This works (well, at least on Forgejo / Codeberg, I don't know about Github). But automatic support for sha-256, or at least a more descriptive error message would be welcome.
The best way is add:
env:
GIT_DEFAULT_HASH: sha256
to the yml file in the job contains the checkout task
Just stumbled onto this whilst trying to work out what was going on, and why I wasn't able to checkout my repo. I guess the vauge error is technically git's fault because they don't seem to be doing any detection on the potential for mismatched hashing? That would explain the very vague error message. Although in their defence, initing the repo rather than cloning it presumably isn't too common.
The best way is add:
env: GIT_DEFAULT_HASH: sha256 to the yml file in the job contains the checkout task
This seems to work well, unless you have submodules that use sha1, where I seem to be having almost the inverse problem:
fatal: couldn't find remote ref 3d80e26f83ccc97f65bd6ec1ed2b7b37b68b7f21000000000000000000000000
It looks to me like it's trying to pad a sha1 to match the expected length of a sha256. I imagine the issue would be the same for any method which forces you to choose between one or the other, rather than detecting it.
Still disappointing to see such a big issue completely unaddressed for well over a year at this point from GitHub's side.
sha256-support stopped being experimental 2023, so this is well overdue. https://github.blog/open-source/git/highlights-from-git-2-45/ .. " In Git 2.29 (released in October 2020), Git gained experimental support for using SHA-256 instead of SHA-1 in specially-configured repositories. That feature was declared no longer experimental in Git 2.42 (released in August 2023)."
For anyone else stuck I was able to get the submodules checked out by using the act-latest image the original reporter used (it seems to be the git version that's important here), and manually running the submodule update command, ignoring the built in functionality of the action.
Just stumbled onto this whilst trying to work out what was going on, and why I wasn't able to checkout my repo. I guess the vauge error is technically git's fault because they don't seem to be doing any detection on the potential for mismatched hashing? That would explain the very vague error message. Although in their defence, initing the repo rather than cloning it presumably isn't too common.
The best way is add: env: GIT_DEFAULT_HASH: sha256 to the yml file in the job contains the checkout task
This seems to work well, unless you have submodules that use sha1, where I seem to be having almost the inverse problem:
fatal: couldn't find remote ref 3d80e26f83ccc97f65bd6ec1ed2b7b37b68b7f21000000000000000000000000It looks to me like it's trying to pad a sha1 to match the expected length of a sha256. I imagine the issue would be the same for any method which forces you to choose between one or the other, rather than detecting it.Still disappointing to see such a big issue completely unaddressed for well over a year at this point from GitHub's side.
Ah to fix that issue for actions/checkout i use this:
steps:
- uses: actions/checkout@v6
with:
ref: master
fetch-depth: 0
submodules: recursive
It works with defined GIT_DEFAULT_HASH=sha256 and if your repo is sha256 and the submodule is sha1, it still works well, tested on Forgejo Actions