"Bad credentials" from ghr (GitHub)

Integrations and Accounts
1

Hi.

My CircleCI upload of artifacts to GitHub that uses ghr is not working anymore and I get this “bad credentials” response but don’t really know why.

I’m now using cimg/go:1.23 base image and pull ghr with go install github.com/tcnksm/ghr@v0.17.0.

I followed the guideline here: GitHub OAuth app integration overview - CircleCI

  1. I validated that I’m using GitHub OAuth app
  2. Generated the ed25519 keypair
  3. Put the public key into GitHub
  4. Put the private key with “Add SSH key” into CircleCI
  5. Added the fingerprint to the CircleCI config.yaml using the fingerprint created with ssh-keygen -E md5 -lf ~/.ssh/circle-ci.

The “Install additional SSH key” job says

Installed key 1f:14:50:c1:4b:f0:ad:b0:f7:8f:05:b1:62:f4:83:da

(BTW: This job does not fail if the fingerprint is not found. I also tried the SHA256 fingerprint (though without any sha256: prefix), which failed to find the key.)

Still I’m getting the following error from ghr:

Failed to get draft release: get release tag: invalid status: 401 Unauthorized GET https://api.github.com/repos/TheRoddyWMS/RoddyToolLib/releases?page=1&per_page=100: 401 Bad credentials []

The used ghr command is

ghr \
              -t "$GITHUB_TOKEN" \
              -u "$CIRCLE_PROJECT_USERNAME" \
              -r "$CIRCLE_PROJECT_REPONAME" \
              -c "$CIRCLE_SHA1" \
              -n "$VERSION" \
              -delete \
              "$VERSION" \
              artifacts/

The strange thing is that this specific endpoint can actually be read without any credentials.

Currently, I’m running out of ideas, what could be wrong, and would appreciate any hints.

2

I also updated the GITHUB_TOKEN now, to be sure a valid one is used. I’m now using a fine-grained token with Content and Action read/write permissions. Still it does not work.

4

I forgot to reference the config.yaml:

I also validated that the fine-grained PAT has the right permissions. Here it says it should be Content(Write) or Content(Write)+Workflows(Write). It reports later as

  • Read access to metadata
  • Read and Write access to code and workflows

Apparently, “code” here also includes “release”. Release was listed also in the things to able to do with the token, when selecting “Content” for the repository permissions.

So, I think the PAT scope is correct.

5

OK. The problem was that I had the GITHUB_TOKEN not only defined in the project, but also in the context. Apparently, the environment variable from the context, which still contained an old token, overrode the one of the project (not exactly intuitive, I think).

Solution: Check your token variable not only in your project, but also in your context.