Checkout: Error: The process '/usr/bin/git' failed with exit code 128

Created on 6 Jan 2021  路  21Comments  路  Source: actions/checkout

Couple of days back this action stopped working.

    - name: Checkout private tools
      uses: actions/checkout@v2
      with:
        repository: tectonic/infrastructure-helm
        token: ${{ secrets.GIT_TECHDEPLOY_TOKEN }}
        path: infrastructure-helm
        fetch-depth: 0
        ref: master
Run actions/checkout@v2
/usr/bin/docker exec  d0faea3798ca7561c881e147e6613d25f75372e481a2c181696cc87de585d470 sh -c "cat /etc/*release | grep ^ID"
Syncing repository: tectonic/infrastructure-helm
Getting Git version info
Initializing the repository
Disabling automatic garbage collection
Setting up auth
Fetching the repository
  /usr/bin/git -c protocol.version=2 fetch --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/*
  remote: Repository not found.
  Error: fatal: repository 'https://github.com/tectonic/infrastructure-helm/' not found
  The process '/usr/bin/git' failed with exit code 128
  Waiting 19 seconds before trying again
  /usr/bin/git -c protocol.version=2 fetch --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/*
  remote: Repository not found.
  Error: fatal: repository 'https://github.com/tectonic/infrastructure-helm/' not found
  The process '/usr/bin/git' failed with exit code 128
  Waiting 11 seconds before trying again
  /usr/bin/git -c protocol.version=2 fetch --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/*
  remote: Repository not found.
  Error: fatal: repository 'https://github.com/tectonic/infrastructure-helm/' not found
  Error: The process '/usr/bin/git' failed with exit code 128

Seems similar to this issue: https://github.com/ad-m/github-push-action/issues/76

Most helpful comment

We also ran into this same issue with all workflows using the checkout action on one of private repos. The issue in our case was with the auth token that gets generated for each run that the checkout action uses by default was not working. We were able to workaround the issue by adding our own PAT as a repo secret and having the checkout action use our token instead:

      - uses: actions/checkout@v2
        with:
          lfs: true
          token: ${{ secrets.ACCESS_TOKEN }}

There were not any changes on our end that would have caused this. The issue just seemingly popped up out of nowhere after working without a problem for months.

At the very least the checkout action could do better error reporting in this case and also check the validity of the token before doing any privileged operations.

All 21 comments

We also experienced a similar issue yesterday in one of our private repositories:

  /usr/bin/git -c protocol.version=2 fetch --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/* +COMMIT_HASH:refs/remotes/pull/PULL_REQUEST_NUMBER/merge
  remote: Repository not found.
  Error: fatal: repository 'https://github.com/sifive/REPOSITORY_NAME/' not found
  The process '/usr/bin/git' failed with exit code 128
  Waiting 12 seconds before trying again
  /usr/bin/git -c protocol.version=2 fetch --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/* +COMMIT_HASH:refs/remotes/pull/PULL_REQUEST_NUMBER/merge
  remote: Repository not found.
  Error: fatal: repository 'https://github.com/sifive/REPOSITORY_NAME/' not found
  The process '/usr/bin/git' failed with exit code 128
  Waiting 16 seconds before trying again
  /usr/bin/git -c protocol.version=2 fetch --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/* +COMMIT_HASH:refs/remotes/pull/PULL_REQUEST_NUMBER/merge
  remote: Repository not found.
  Error: fatal: repository 'https://github.com/sifive/REPOSITORY_NAME/' not found
  Error: The process '/usr/bin/git' failed with exit code 128

This happened at around Jan 5, 2021, 7:05 PM PST. The issue seems to have gone away now, but I just wanted to add some extra information in case if it's useful.

Doesn't appear to be fixed for me 鈽癸笍

Without ref: master this is the output:

Run actions/checkout@v2
  with:
    repository: tectonic/infrastructure-helm
    token: ***
    path: infrastructure-helm
    fetch-depth: 0
    ssh-strict: true
    persist-credentials: true
    clean: true
    lfs: false
    submodules: false
  env:
    XDG_DATA_HOME: /root/.local/share
    KUBECONFIG: /root/kubeconfig
    AWS_DEFAULT_REGION: eu-central-1
    AWS_REGION: eu-central-1
    AWS_ACCESS_KEY_ID: ***
    AWS_SECRET_ACCESS_KEY: ***
/usr/bin/docker exec  391d5591308f1b002e6fa53e803efc54eab81186507cdf92652262f21b79d9ef sh -c "cat /etc/*release | grep ^ID"
Syncing repository: tectonic/infrastructure-helm
Getting Git version info
Initializing the repository
Disabling automatic garbage collection
Setting up auth
Determining the default branch
  Retrieving the default branch name
  Not Found
  Waiting 13 seconds before trying again
  Retrieving the default branch name
  Not Found
  Waiting 17 seconds before trying again
  Retrieving the default branch name
  Error: Not Found

I'm having the same issue

same issue here

did anyone reached a solution?

Same here. Thanks!

Seems to be an issue with the token handed out to the CI runner. When I used one generated manually and passed it via with.token, cloning worked fine.

We were facing the same issue in private repos.
We changed to one version older release and that seems to work.

We changed it to:

   - uses: actions/checkout@a81bbbf8298c0fa03ea29cdc473d45769f953675

(which is release 2.3.3 https://github.com/actions/checkout/releases/tag/v2.3.3 )

What is root cause though?

Same problem too. Just getting this now

How to solve this problem?

We also ran into this same issue with all workflows using the checkout action on one of private repos. The issue in our case was with the auth token that gets generated for each run that the checkout action uses by default was not working. We were able to workaround the issue by adding our own PAT as a repo secret and having the checkout action use our token instead:

      - uses: actions/checkout@v2
        with:
          lfs: true
          token: ${{ secrets.ACCESS_TOKEN }}

There were not any changes on our end that would have caused this. The issue just seemingly popped up out of nowhere after working without a problem for months.

At the very least the checkout action could do better error reporting in this case and also check the validity of the token before doing any privileged operations.

same issue here folks, and also used PAT as a workaround 馃憤馃徏

mine is weirder hah

checkout completes successfully but produces an annotation, and clicking the annotation brings me to the logs page but doesn't focus any logs. looking at the logs, all looks normal

EDIT: nevermind, mine is a problem that is my fault, disregard

We also ran into this same issue with all workflows using the checkout action on one of private repos. The issue in our case was with the auth token that gets generated for each run that the checkout action uses by default was not working. We were able to workaround the issue by adding our own PAT as a repo secret and having the checkout action use our token instead:

Same issue here for tokens generated for schedule, workflow_dispatch, and issue_comment triggered runs. Tokens issued for pull_request triggered runs worked fine.

reported those comments to github c:

saw this today too. is it just me or is github looking and behaving more like microsoft devops everyday?

I have had a support case open with Github Support for this since I initially ran into it last month and they reported that there is a pull request currently waiting to be merged to address this. They would not share any further details regarding the nature of the fix or a timeline for it to be merged/released.

I get this error when trying to update docker container with testcafe to run the tests on. There is no error when it comes to containers... but git throws in this action. Extremely weird and blocking...

according to similar error in fisheye docs
https://confluence.atlassian.com/fishkb/non-zero-exit-code-128-error-executing-command-unable-to-find-remote-helper-for-http-305759561.html

"This ERROR is caused when you have an Environment Variable called GIT_EXEC_PATH."

Hmm. Following this trail i found https://www.xspdf.com/resolution/59948454.html which seems like an aggregation of different forums threads about it. And it seems like error 128 can mean a lot of diferent things, including wrong SSH keys.
Maybe SSH keys are not propagated correctly from the GHA to Checkout action?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

chorrell picture chorrell  路  4Comments

rster2002 picture rster2002  路  7Comments

lukka picture lukka  路  6Comments

gordinmitya picture gordinmitya  路  7Comments

jcharnley picture jcharnley  路  4Comments