checkout icon indicating copy to clipboard operation
checkout copied to clipboard

actions/checkout fails on git repos that use SHA256

Open jwildeboer opened this issue 1 year ago • 8 comments

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.

jwildeboer avatar Aug 03 '24 21:08 jwildeboer

Is there any updates on this issue?

this is still relevant.

Ittihadyya avatar Nov 26 '24 14:11 Ittihadyya

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!

ElanHR avatar Feb 07 '25 04:02 ElanHR

#1945 is still waiting for a response from a codeowner.

yangskyboxlabs avatar Mar 06 '25 00:03 yangskyboxlabs

Still no news?

xlionjuan avatar Jun 03 '25 14:06 xlionjuan

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

EvanCarroll avatar Sep 26 '25 20:09 EvanCarroll

I believe this also stops you from you from using repo-actions hosted in sha256 repositories.

EvanCarroll avatar Oct 24 '25 16:10 EvanCarroll

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.

Fuzzillogic avatar Dec 08 '25 21:12 Fuzzillogic

The best way is add:

env:
    GIT_DEFAULT_HASH: sha256

to the yml file in the job contains the checkout task

vuthanhtrung2010 avatar Jan 01 '26 05:01 vuthanhtrung2010

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.

Cwavs avatar Jan 01 '26 12:01 Cwavs

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)."

janderssonse avatar Jan 01 '26 18:01 janderssonse

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.

Cwavs avatar Jan 01 '26 19:01 Cwavs

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.

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

vuthanhtrung2010 avatar Jan 02 '26 03:01 vuthanhtrung2010