GitHub App installation token returns "bad-credentials" for github-digest datasource after 43.84.0

[korosuke613]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitHub.com

Which version of Renovate are you using?

43.84.2 (first occurred on 43.84.0)

Please tell us more about your question or problem

After upgrading from 43.83.2 to 43.84.0, the github-digest datasource fails with bad-credentials when resolving digests for private repositories using a GitHub App installation token passed via --token. This issue persists on 43.84.2.

The suspected cause is the change introduced in #40225 ("github-actions: Support digests for non-semver refs"), which routes non-semver refs to the github-digest datasource instead of github-tags. Prior to 43.84.0, these refs were resolved via queryTags (which works with our GitHub App installation token). After 43.84.0, they are resolved via queryBranches in GithubGraphqlDatasourceFetcher, which returns bad-credentials with the same token.

How I run Renovate

Self-hosted via pnpm dlx renovate in GitHub Actions.

• GitHub.com (not GHES)
• Authentication: GitHub App installation token via actions/create-github-app-token@v2 with owner scope
• Token is passed as --token CLI argument
• GitHub App repository permissions:
  • Read and write: Checks, Commit statuses, Contents, Issues, Pull requests, Workflows
  • Read only: Dependabot alerts, Metadata
• GitHub App organization permissions:
  • Read only: Members

Minimal reproduction

This issue requires a private repository referenced via GitHub Actions reusable workflow with digest pinning.

Steps to reproduce:

1. Create a GitHub App with access to private repositories in an organization
2. Generate an installation token scoped to the org
3. Run pnpm dlx renovate@43.84.0 --token <app-installation-token> <repo> against a repository that depends on another private repo via GitHub Actions reusable workflow (with digest pinning)
4. Observe bad-credentials from github-digest datasource

A public-only reproduction may not trigger the bug, as the token scoping behavior differs for public vs private repos.

Expected behavior

The github-digest datasource should use the platform token (passed via --token) for GraphQL API calls, as github-tags does successfully in 43.83.2.

Workaround

Pin Renovate to 43.83.2.

Logs (if relevant)

Logs

DEBUG: Datasource unknown error (repository=<SAME_ORG>/<REPO_A>)
       "datasource": "github-digest",
       "packageName": "<SAME_ORG>/<REPO_B>",
       "err": {
         "message": "bad-credentials",
         "stack": "Error: bad-credentials
    at handleGotError (.../renovate/lib/util/http/github.ts:175:14)
    at GithubHttp.handleError (.../renovate/lib/util/http/github.ts:382:11)
    at GithubHttp.request (.../renovate/lib/util/http/http.ts:271:12)
    at processTicksAndRejections (node:internal/process/task_queues:104:5)
    at GithubHttp.requestJsonUnsafe (.../renovate/lib/util/http/github.ts:396:20)
    at GithubHttp.requestJson (.../renovate/lib/util/http/http.ts:384:17)
    at GithubGraphqlDatasourceFetcher.doRawQuery (.../renovate/lib/util/github/graphql/datasource-fetcher.ts:129:17)
    at GithubGraphqlDatasourceFetcher.doShrinkableQuery (.../renovate/lib/util/github/graphql/datasource-fetcher.ts:203:20)
    at GithubGraphqlDatasourceFetcher.doPaginatedFetch (.../renovate/lib/util/github/graphql/datasource-fetcher.ts:266:27)
    at GithubGraphqlDatasourceFetcher.doCachedQuery (.../renovate/lib/util/github/graphql/datasource-fetcher.ts:307:7)
    at GithubGraphqlDatasourceFetcher.getItems (.../renovate/lib/util/github/graphql/datasource-fetcher.ts:345:17)
    at GithubGraphqlDatasourceFetcher.query (.../renovate/lib/util/github/graphql/datasource-fetcher.ts:60:19)
    at queryBranches (.../renovate/lib/util/github/graphql/index.ts:41:15)
    at async Promise.allSettled (index 1)
    at .../renovate/lib/modules/datasource/github-digest/index.ts:61:48
    at withCache (.../renovate/lib/util/cache/package/with-cache.ts:115:18)"
       }

[jamietanna]

cc @zharinov if you're able to take more of a look

I think we may need more logs @korosuke613 @markelliot

[korosuke613]

Hi, @jamietanna , Thank you for response.

Since our original environment uses private repositories within an organization, I cannot share the full logs publicly. Instead, I reproduced the issue using my personal repositories.

I was able to reproduce the issue. Here are the details:

Reproduction repository

• Public (Renovate target): korosuke613/renovate-issue-repro
• Private (referenced via @main): korosuke613/renovate-issue-repro-private

The public repo has a workflow that references a reusable workflow from the private repo using a branch ref (@main). I created a dedicated GitHub App and installed it on both repositories to generate the installation token.

Reproduction runs

• 43.83.2 (success): https://github.com/korosuke613/renovate-issue-repro/actions/runs/23435182682/job/68171344920 (full log: 43.83.2.txt)
• 43.84.2 (failure): https://github.com/korosuke613/renovate-issue-repro/actions/runs/23435204905/job/68171422500 (full log: 43.84.2.txt)

Key finding

• 43.83.2: Branch refs like @main are treated as "unsupported/unversioned value" and skipped — github-digest datasource is never called.
• 43.84.2: Branch refs are now processed via the github-digest datasource, which calls the GraphQL API. This returns bad-credentials when using a GitHub App installation token against a private repository.

I initially reported that this worked correctly on 43.83.2, but it turns out branch refs were simply being skipped rather than successfully resolved. Apologies for the confusion in my original report.

[jamietanna]

Tracking issue: #42077

[jamietanna]

Should be resolved in 43.89.2