Error: fatal: could not read Username for 'https://github.com': terminal prompts disabled

[jason-ausmus]

Hello,

I'm attempting a rollback flow using actions/checkout@v2. The problem is that I need to use a PAT in order to rollback commits that change Github Workflows and when I pass that PAT into actions/checkout, I get an error.

Error: fatal: could not read Username for 'https://github.com': terminal prompts disabled

My workflow:

name: "Dev Deploy"
on:
  workflow_run:
    workflows: ["Versioning"]
    types: [completed]
jobs:
  fail_job:
    runs-on: ubuntu-latest
    steps:
      - name: Fail
        run: |
          exit 1
  rollback-on-failure:
    runs-on: ubuntu-latest
    needs: [fail_job]
    if: always() && needs.fail_job.result == 'failure'
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
          token: ${{ secrets.WORKFLOW_TOKEN }}
      - run: chmod +x environment/rollback.sh && ./environment/rollback.sh

The PAT used has the permissions to change workflows, as well as repository permissions. The issue seems to be that the action doesn't allow me to set a username before it tries to fetch the repository.

[adamevers]

I'm having similar issues. Did you ever find a fix @jason-ausmus?

My workflow:

name: Android Beta Prod Distribution

on:
  push:
    branches:
      - android-beta-prod-workflow

jobs:
  beta-distribution:
    runs-on: ubuntu-latest
    name: Beta Distribution
    steps:
    - name: Checkout
      uses: actions/checkout@v2
    - uses: actions/setup-node@master
    - uses: c-hive/gha-yarn-cache@v1

    - name: Clone repo
      uses: actions/checkout@v2
      with:
        repository: believrapp/api-env
        ref: main
        path: cloned-secrets
        token: $ {{ secrets.GH_TOKEN}}

[svc-instala]

same issue here with a PAT

[jason-ausmus]

@adamevers surprisingly it did start working for me when I added the repository to the with with statement. I can't really account for why that fixed it, but it's been running smoothly for me now since I did that.

[MikulasMascautanu]

I'm also experiencing the same issue. I wanted to add a checkout of another private repo, that lives in the same organisation as the original private repo which the workflow is in.

My code:

     - name: Checkout the private repo in which the workflow lives
        uses: actions/checkout@v2
      - name: Checkout a public repo to see if it works
        uses: actions/checkout@v2.3.4
        with:
          repository: actions/checkout
          ref: main
      - name: Checkout another private repo in the same organisation
      (and provide a PAT with repo, read:user and user:email permissions)
        uses: actions/checkout@v2.3.4
        with:
          repository: org/private-repo
          ref: master
          token: $MY_PAT

Results:
Checkout the private repo in which the workflow lives ✔️
Checkout a public repo to see if it works ✔️
Checkout another private repo in the same organisation ❌

The error:

[ghost]

@MikulasMascautanu Were you able to fix this issue ? If yes, please do share. thank you

[dszakallas]

I stumbled into the same error message and found this issue. However in my case, the cause of the problem was that the token expired. 😅
Adding it here, in case it helps folks. The error message is very undescriptive.

[MichaIng]

Another hint: The PAT must have an expiry date, otherwise the same error appears 😅.

[Ritalina]

Has anyone found a solution to this issue? I have the same error and nothing seems to work

[MikulasMascautanu]

Hi, sorry for my late response.
I did NOT solve the issue, I used a different approach for my original task.
Sorry:/

[MichaIng]

You definitely use a PAT which has an expiry date and is not expired?

[Ritalina]

Hi, sorry for my late response. I did NOT solve the issue, I used a different approach for my original task. Sorry:/

Thanks, I think the same, I will change my strategy. :)

[shrutiburman]

Another hint: The PAT must have an expiry date, otherwise the same error appears 😅.

@MichaIng
Thanks for the tip! I wouldn't have figured that out on my own. :)

[david-renner-dwg]

@MichaIng Is the PAT something you generate yourself? Or is that the same access token we can reference with ${{secrets.GH_TOKEN}}

[MichaIng]

@MichaIng Is the PAT something you generate yourself? Or is that the same access token we can reference with ${{secrets.GH_TOKEN}}

The "Personal Access Token" is what you need to create yourself in your account's developer settings. In my case, AFAIK, it was required for a workflow to checkout and push to a branch/PR created by dependabot, which didn't work with the default GitHub actions token.

[pcbuildpluscoding]

I needed to auto-create a release for my private golang repository, and came across this page in my investigations. Being new to github actions and workflows, I needed to resolve how to inject https://$GH_TOKEN@github.com instead of https://github.com
gitconfig statement into my workflow setup. Found this blog post which exactly solved my issue. Posting here in case someone else needs a pointer

[ScottG489]

Using a token that doesn't expire fixed this issue for me.

Could someone explain if there is some underlying reason why these tokens are rejected though?

If GitHub is going to reject tokens that don't expire then they shouldn't let you generate them in the first place.

[pcbuildpluscoding]

@ScottG489 - have a look at this blog post. Seems there are 3 requirements for a valid token applied in actions.

1. It belongs to the right user or organization account
2. It has repository scope
3. It is not expired

[ola-adolfsson-ipex]

I had somewhat the same issue.

I just removed the token.

 - name: Clone repo
      uses: actions/checkout@v2
      with:
        repository: believrapp/api-env
        ref: main
        path: cloned-secrets
        token: $ {{ secrets.GH_TOKEN}} <-- removed this line.

Hope it helps someone :)

[MichaIng]

For a simple checkout indeed no PAT is required.

[boly38]

my 2 cents: it would be great that github checkout action automatically detect this kind of error return to provide a tips on this: (example: please verify your token and expiration date.

I think in many case this is just "private" + "expired" or "wrong" PAT configuration?

[papanito]

@boly38 good idea. I was also very confused by the message, but ultimately I juts had the token not configured

[ghost]

Should the requirement to have an expiration date in the PAT be documented here?
https://github.com/marketplace/actions/checkout#usage

[pidgezero-one]

I'm having the same problem as MikulasMascautanu, but I don't think there's anything wrong with my PAT. I'm only getting this error on one private repo in the entire organization. Every other repo in the same organization is completing its actions just fine, and they all use an identical CI yaml (the only difference being that this one specifies a working directory).

Is there some repo setting in Github that I might need to change?

[ocervell]

Personally I didn't have a PAT in my GitHub workflow and it worked fine till 2 weeks ago for simple checkout, so not sure what happened on GitHub side here.

[alexey-berdyugin]

Looks like I found the root cause of this behavior.
When the first actions/checkout@v2 performs without any options for current repository it caches github token in local git store and further the same token is used. I added flag "persist-credentials: false" to the first checkout step and further steps with github communications started work (ad-m/github-push-action or simple git push https://user:token@github/org/repo). Looks like git cli ignores incoming token if it is already stored in local storage..
At lest it helped me.. :-)
p.s. username does not matter when token is used..

[pidgezero-one]

@alexey-berdyugin Interesting! Could I please see an example of how you configured this? I saw this post which is making me scared to try it !

[alexey-berdyugin]

In my case:

      - name: Checkout Application Repo
        uses: actions/checkout@v3
        with:
          path: app_repo
          persist-credentials: false
  # other steps
      - name: Push changes
        uses: ad-m/github-push-action@master
        with:
          github_token: ${{ steps.get_github_token.outputs.git_app_token }}
          directory: app_repo
          branch: ${{ github.ref }}
  # Or simple
      - name: Manual push
        run: |
          cd app_repo
          git config --local user.email "4github-actions@users.noreply.github.com"
          git config --local user.name "github-actions"
          git diff-index --quiet HEAD || git commit -a -m "Test"
          gut push https://<any-user_or_app-id>:<token>@github.com/user_or_org/repo.git

[willinDrive]

Works for me with actions/checkout@v2, but with actions/checkout@v3 shows error from the topic

[ddsharpe]

I had the same error on multiple repositories. Tried checkout@v3 and v4, but result was the same. For me, replacing the Action secret in each repository with a new Personal Access Token (with expiration) solved it.

[MichaIng]

I had the strange case where repeating the failed job(s) after updating the PAT did not work (resulting in the same error). Finally it did work when I re-triggered the same workflow with an empty amended commit. Are secrets somehow hardcoded once a workflow/job is triggered, so that re-runs do not get changed secrets (and variables)?

[ljmf00-wekaio]

I'm having the same issues, inconsistent failures on checkout with a PAT.

[ljmf00-wekaio]

Setting this before the action solved the issue:

git config --global credential.https://gh.neting.cc.username git
git config --global credential.https://gh.neting.cc.password <your-pat>

Don't forget to hook and remove the password after checkout

[sergiomayo44]

I'm using a github repo, and unless I create a personal access token, i can't pull.
So inside the ".git" folder, I modified the file "config".
In the [remote "origin"] section set url to
url = https://yourusername:yourpersonalaccesstoken@github.com/...

[themathmagician]

In my case the PAT was correct, but the checkout branch did not exist. What and oddly worded error message!

[omgupta1608]

None of the different workarounds and solutions worked for me. Tried the following

• With and without persist-credentials: false
• With and without token expiry date
• With and without:

env:
      GH_ACCESS_TOKEN: ${{ secrets.GH_ACCESS_TOKEN }}
steps:
- run: git config --global credential.https://gh.neting.cc.username myusername
- run: git config --global credential.https://gh.neting.cc.password $GH_ACCESS_TOKEN

• All checkout versions v2, v3 and v4

Nothing works for me!

[frans-slabbekoorn]

I got it working using checkout@v3 with persist-credentials: false and a PAT with expire date using the following config:

git config --global user.name myusername
git config --global user.email myemail
git remote set-url origin https://x-access-token:${{ secrets.PAT }}@github.com/${{ github.repository }}
...git operations

[gimi-anders]

I am having the same issue. It only happens for PRs created by dependabot though, and the strange thing is that if I close the PR and then reopen it, then it works.
I have tried to apply all fixes suggested here, but nothing seems to work.

Update: I got it working now. I just realised that I had to update the PAT in two places - both for the actions and for dependabot.

[georg-eckert-zeiss]

I was able to fix this by using a classic token with the permissions public_repo, read:user and user:email.

Cheers

[plowsof]

this is one of those 'why is nothing easy / the world is against me' problems. the comment from @frans-slabbekoorn fixed it for me. Thank you to others who mentioned the PAT requiring an expiry date.

[RobertDeibel]

Hey, just stumbled across this, while encountering the same error message. We use a organization wide deploy key, when checking out with the recursive and token option during parent repo checkout I encountered the same issue. It was fixed by explicitly checking out the submodule as an own repo:

      - name: Checkout
        uses: actions/checkout@v4
        with:
          persist-credentials: false
        #   submodules: recursive                      <----- this is not working
        #   token: ${{ secrets.DEPLOY_KEY }}   <-----
      - name: clone submodule
        uses: actions/checkout@v4
        with:
          repository: <organization>/<repo-name>
          ref: main
          path: ${{ github.workspace }}/path/to/submodule
          ssh-key: ${{ secrets.DEPLOY_KEY }}
          persist-credentials: false

Maybe this will help someone.

[georg-eckert-zeiss]

I was able to fix this by using a classic token with the permissions public_repo, read:user and user:email.

Cheers

Please explain the downvotes so I can learn from it.

[MichaIng]

Please explain the downvotes so I can learn from it.

I did not downvote it, but I did not find your comment very helpful either. It is potentially problematic without more context, given that people tend to just copy&paste (take over without scrutinise whether it fits to their use case) all they find. Which PAT (classic, modern, permissions?) did throw the error before? Then narrow down the minimal required change for this case. If it was not already known/commented before, then we might have another condition, everyone can check 🙂.

In my case, public_repo is sufficient to check out a public repo with a classic PAT, while permissions to access user data and email is not required. In my case, it was the missing expiry date only, which made the difference, to checkout a public repo with classic as well as modern PAT. So that is one condition everyone can check.

[xeruf]

Hey, just stumbled across this, while encountering the same error message. We use a organization wide deploy key, when checking out with the recursive and token option during parent repo checkout I encountered the same issue. It was fixed by explicitly checking out the submodule as an own repo:

      - name: Checkout
        uses: actions/checkout@v4
        with:
          persist-credentials: false
        #   submodules: recursive                      <----- this is not working
        #   token: ${{ secrets.DEPLOY_KEY }}   <-----
      - name: clone submodule
        uses: actions/checkout@v4
        with:
          repository: <organization>/<repo-name>
          ref: main
          path: ${{ github.workspace }}/path/to/submodule
          ssh-key: ${{ secrets.DEPLOY_KEY }}
          persist-credentials: false

Maybe this will help someone.

Except this makes it ignore the referenced commit of the submodule, making the build non-reproducible

See also #1382

[RobertDeibel]

Hey, just stumbled across this, while encountering the same error message. We use a organization wide deploy key, when checking out with the recursive and token option during parent repo checkout I encountered the same issue. It was fixed by explicitly checking out the submodule as an own repo:

      - name: Checkout
        uses: actions/checkout@v4
        with:
          persist-credentials: false
        #   submodules: recursive                      <----- this is not working
        #   token: ${{ secrets.DEPLOY_KEY }}   <-----
      - name: clone submodule
        uses: actions/checkout@v4
        with:
          repository: <organization>/<repo-name>
          ref: main
          path: ${{ github.workspace }}/path/to/submodule
          ssh-key: ${{ secrets.DEPLOY_KEY }}
          persist-credentials: false

Maybe this will help someone.

Except this makes it ignore the referenced commit of the submodule, making the build non-reproducible

See also #1382

You can pass a reference parameter to this action that holds the correct SHA you want to checkout. To do this from an action you can save it in an environment variable.

  - name: Get submodule SHA
        run: |
          cd root_dir
          echo "Getting the submodule at: ""$(git rev-parse HEAD:path/to/submodule)"
          echo "submodule_sha=$(git rev-parse HEAD:path/to/submodule)" >> "$GITHUB_ENV"
          cd ${{ github.workspace }}
      - name: clone submodule
        uses: actions/checkout@v4
        with:
          ssh-key: ${{ secrets.DEPLOY_KEY }}
          repository: <organization>/<repo>
          ref: ${{ env.submodule_sha }}
          path: ${{ github.workspace }}/path/to/submodule
          persist-credentials: false

[StevenACoffman]

The layers of their javascript between you and a git command will not be updated to make more friendly error messages upon failure.

Instead, if you add a step to your own workflow you can emit helpful action items for when errors occur and save your future self from wasting time.

You can verify your Personal Access Token is not expired and has proper permissions:

GitHub:

curl -XGET -H 'authorization: token <personal token>' '<https://api.github.com/repos/><owner>/<repo>'

GitHub Enterprise:

curl -XGET -H 'authorization: token <personal token>' 'https://<GHE url>/api/v3/repos/<owner>/<repo>'

So for instance:

curl -XGET -H 'authorization: token '"${GHBOT_TOKEN}" https://api.github.com/repos/MyOrg/MyRepo

So write a quick script to use as a step in your workflow:

echo "Checking GitHub Personal Access Token for expiry and/or access"
# prepend some arguments, but pass on whatever arguments this script was called with
output="$(curl -XGET \
--write '\n%{http_code}\n'  \
--silent \
--fail -H 'Content-Type:application/json' \
-H 'Accept:application/json' \
-H 'authorization: token '"${GHBOT_TOKEN}" https://api.github.com/repos/MyOrg/MyRepo \
)"
return_code=$?
if [ 0 -eq $return_code ]; then
    # remove the "http_code" line from the end of the output, and parse it
    echo "Yay! Your personal access code is not expired and has access to this repo"
else
    echo "Boo! Your personal access code is expired or has no access"
   # comment the next line if you don't want to see the HTTP status code and return messages from GitHub
   echo "Failure: code=$output"
   exit 1
fi