fatal: could not read Username for 'https://github.com': No such device or address (using checkout v3)

[theofficialgman]

git-auto-commit Version

v5.0.0

Machine Type

Ubuntu (eg. ubuntu-latest)

Bug description

fatal: could not read Username for 'https://github.com/': No such device or address
Error: Invalid status code: 128
    at ChildProcess.<anonymous> (/home/runner/work/_actions/stefanzweifel/git-auto-commit-action/v5/index.js:17:19)
    at ChildProcess.emit (node:events:514:28)
    at maybeClose (node:internal/child_process:1105:16)
    at ChildProcess._handle.onexit (node:internal/child_process:305:5) {
  code: 128
}
Error: Invalid status code: 128
    at ChildProcess.<anonymous> (/home/runner/work/_actions/stefanzweifel/git-auto-commit-action/v5/index.js:17:19)
    at ChildProcess.emit (node:events:514:28)
    at maybeClose (node:internal/child_process:1105:16)
    at ChildProcess._handle.onexit (node:internal/child_process:305:5)

https://github.com/Botspot/pi-apps/actions/runs/7676180845/job/20923541957

Steps to reproduce

https://github.com/Botspot/pi-apps/actions/runs/7676180845/workflow

this workflow clones the repo using actions/checkout@v3, operates on that checkout (edits files), and then uses actions/upload-artifact@v3 to upload that as an artifact. In a separate job, that previous artifact is downloaded with actions/download-artifact@v3, some additional changes are made (some changes are reverted if there are failures), and then stefanzweifel/git-auto-commit-action@v5 is called, which fails. Previously this action was used to commit and make a PR to the repo with peter-evans/create-pull-request@v4 with no such issues. This was the commit change to attempt to switch to your project Botspot/pi-apps@0b3c623

Tried solutions

No response

Example Workflow

https://github.com/Botspot/pi-apps/actions/runs/7676180845/workflow

Relevant log output

No response

[stefanzweifel]

Thanks for reporting.

Currently not in front of a desktop, but I guess the problem is that actions/checkout is not used in your 2nd job, when you download the artifact.

actions/checkout is responsible for setting up authentication and I guess this "stuff" gets lost when you zip it up with upload-artifact.

Can you maybe specify, that the .git folder is also included in the artifact? Or also use actions/checkout in your 2nd job.

Will take a closer look, when I'm back in front of a desktop next week.

[theofficialgman]

Can you maybe specify, that the .git folder is also included in the artifact?

actions/checkout@v3 does not appear to include a .git folder. As seen by the verbose log output from Tar GITHUB_WORKSPACE step, there is no .git folder being packaged. the tar command used is tar -C $GITHUB_WORKSPACE -cvf GITHUB_WORKSPACE.tar . and I can confirm that on a locally cloned git repo it compresses the existing .git folder to the tarfile. The tar command by definition includes all hidden files.
https://github.com/Botspot/pi-apps/actions/runs/7676180845/job/20923382346

Or also use actions/checkout in your 2nd job.

No, the first job edits the repo and uploads an artifact. 2nd job pulls the artifact and (I skipped telling you this) tests those changes on multiple OS chroots (test systems) and set variables for failures. 3rd job pulls the artifact from 1st job and the variables from the multiple containers, reverts changes (changes are staging in the git repo so easy to revert), and then attempts to push (where the failure is).

[theofficialgman]

Sorry misread my own log. .git is present the in the tar archive as well as when extracted

I have added extra debugging right before running git-auto-commit-action and can confirm that .git and subdirectories are present. feel free to review the output here https://github.com/Botspot/pi-apps/actions/runs/7676934333/job/20925182095#step:6:34

[theofficialgman]

I also grabbed git config --list output right after doing the checkout and right before doing the commit

only difference that I can see is that github no longer hides the authentication token on the second job (probably because its a token from the first job)

[benpocalypse]

Out of nowhere, with an automation that has worked fine for the past several months, I'm running into this same issue. I wonder if it's something that changed on Github's end?

It was my fault. User error...derp. My problem was not in the action - it was because my program was somehow deleting my .git folder. Sorry for the bother.

[theofficialgman]

only difference that I can see is that github no longer hides the authentication token on the second job (probably because its a token from the first job)

I believe that this token is only valid for the github job that it is created in. For now (and I have been doing this for about a month now) I simply run another checkout command (at the same hash as the first one) in the second job. That populates the github environment with a valid token and populates the .git folder. Then I extract everything but the .git folder from the .tar archive

https://github.com/Botspot/pi-apps/pull/2540/files