fatal: could not read Password for 'https://***@github.com': No such device or address

[ericclemmons]

Describe the bug

Since upgrading from 9.4.1 to 9.17.1, merges seem to be publishing, but the GitHub release is failing with:

fatal: could not read Password for 'https://***@github.com': No such device or address
– ericclemmons/codelift@f03c447#diff-b9cfc7f2cdf78a7f4b91a753d10865a2

To Reproduce

https://github.com/ericclemmons/codelift/runs/492760247

Expected behavior

Screenshots

Environment information:

Environment Information:

"auto" version: v9.17.1
"git"  version: v2.21.1 (Apple Git-122.3)
"node" version: v10.16.3

Project Information:

✔ Repository:      ericclemmons/codelift
✔ Author Name:     Eric Clemmons
✔ Author Email:    eric@smarterspam.com
✔ Current Version: v1.0.4
✔ Latest Release:  v1.0.0

✔ Labels configured on GitHub project

GitHub Token Information:

✔ Token:            [Token starting with 407a]
✔ Repo Permission:  admin
✔ User:             ericclemmons
✔ API:              https://api.github.com
✔ Enabled Scopes:   repo
✔ Rate Limit:       4964/5000

Additional context

Testing out changing package.json's repository value to git@github.com:ericclemmons/codelift.git...

[hipstersmoothie]

I very recently changed how the auth works to put your token in the remote url to get around of ssh wonkiness. #969

taking a look right now

[hipstersmoothie]

I think this line is not executing correctly. Gonna check on one of my github actions projects.

https://github.com/intuit/auto/pull/969/files#diff-54899627ccbe2e33cc90970d5e6d5191R482

[hipstersmoothie]

I matched your setup on this repo and it seems to work. One thing that stands out to me is that you use the GITHUB_TOKEN instead of making a GH_TOKEN with the correct permissions.

More info here

My repo with working actions

[hipstersmoothie]

Not so working anymore

[ericclemmons]

What's peculiar is that it used to work...

I was going off of this, where I was reassigning GITHUB_TOKEN (which should exist by default) to GH_TOKEN to match:

https://help.github.com/en/actions/configuring-and-managing-workflows/authenticating-with-the-github_token#using-the-github_token-in-a-workflow

(I only have NPM_TOKEN defined as a secret).

I'll charge my laptop, try out a try out some changes and, get this resolved!

[hipstersmoothie]

Sorry for the failed releases! I just made a PR with what I think should work My repo here is working in a similar fashion.

Reading the docs it seem the main fork might have access to the repo scope

[hipstersmoothie]

Ah yeah the GITHUB_TOKEN works. I don't think it did in the past. This is a nice improvement,

https://github.com/hipstersmoothie/create-check/runs/492870082?check_suite_focus=true

[hipstersmoothie]

Also tried the way you specified the repo

https://github.com/hipstersmoothie/create-check/runs/492899725?check_suite_focus=true

[hipstersmoothie]

Found a bug in verbose logging in github actions.

I think I'm gonna fork your repo and, switch to git-tag releases and see if I can get the error too

[hipstersmoothie]

I seem to have to working on my fork too. So I think I've either solve the issue or still failed to reproduce

https://github.com/hipstersmoothie/codelift-test/runs/493031548?check_suite_focus=true

[ericclemmons]

One thing that stands out to me is that you use the GITHUB_TOKEN instead of making a GH_TOKEN with the correct permissions.

Ah, this part is what's different:

https://intuit.github.io/auto/pages/getting-started.html#2.-environment-variables

From the beginning, I relied on the default GITHUB_TOKEN. With the latest updates, looks like having an explicit token (eg. GH_TOKEN) should resolve it.

BRB!

[ericclemmons]

Yikes, I'm getting further away from a solution here.

I've been testing out GITHUB_TOKEN, reverting commits, the works in https://github.com/ericclemmons/codelift/pull/98.

1. Last "working" release on master:

   https://github.com/ericclemmons/codelift/runs/491853289?check_suite_focus=true#step:6:279

2. Next release "passes", but clearly has a problem:

   fatal: Not a valid commit name 39499457af1237ea3445da71ea6e3ada00489a57

   https://github.com/ericclemmons/codelift/runs/492755127?check_suite_focus=true#step:6:90

   This is from the PR where I updated auto and several other dependencies, ericclemmons/codelift@f03c447 in particular.

3. Subsequent PRs have either that same Not a valid commit name eror, or the could not read Password error:

   https://github.com/ericclemmons/codelift/actions?query=workflow%3ARelease+branch%3Amaster

I'm going to reset back before upgrading auto and try to get https://github.com/ericclemmons/codelift/pull/98 passing again, then upgrade auto in a separate PR.

[ericclemmons]

Merged in https://github.com/ericclemmons/codelift/pull/98 & going to see if master builds successfully...

[ericclemmons]

Downgrading auto fixed it:

https://github.com/ericclemmons/codelift/runs/493754731

I'll have to look into specifics, but there was a lot of weirdness in #1034 (comment)...

[hipstersmoothie]

I think the errors you saw were because git fetch --tags does not fetch the commit history.

Seems like checkout v2 https://github.com/actions/checkout/:

Only a single commit is fetched by default, for the ref/SHA that triggered the workflow.

So when we runt git describe --tags at some point we have the tag, but not the commit it points to. Reading their docs it seems the following command might be better to get the full history:

 git fetch --prune --unshallow

Errors that would be fixed by a full commit history:

• fatal: No tags can describe '4b5e22a853f1591001fdb0ef6671d4cb910a2a38'.

---

I'm not sure that you saw it but I submitted a PR with what I though would fix it. I added the above findings to it just now. Part of it is that I made a few Github Actions related bug fixes in #1036 I also included in the PR.

[hipstersmoothie]

This message fatal: Not a valid commit name 39499457af1237ea3445da71ea6e3ada00489a57 is because of this line. It is how we check that there are no commits on the remote. We do this so that you don't get a botched release from merging 1 pr while another is being released.

This message was printed at 4:47 PM PST and references commit 39499457af1237ea3445da71ea6e3ada00489a57.

Looking at the git log the merge commit is here

and the commit with the hash that caused the release

I'm just gonna guess that even though my time in my git tool says 3:47 this is in fact 4:47. So it seems like you merged/made the Add Badges commit at almost the same exact times as you project was being versioned by auto. This feature was introduced in #1018.

If we did not do this check, your release still would have failed after publishing when trying to push the changelog and new version back to master because fo 39499457a.

The build for 39499457a fails for the same reason. The next commit was made directly to master so the previous release is aborted.

I will make sure to make a PR to ignore that error message as it's misleading.

[hipstersmoothie]

Looks like your release worked 🚀 @ericclemmons You'll probably want to disable logs since they are super verbose.

This was fixed by #1036

[ericclemmons]

Alright, lots of movement in this one, resolved thanks to @hipstersmoothie!

https://github.com/ericclemmons/codelift/pull/97#issuecomment-596258170

I opened a PR back to make Auto's example match:

#1037