Repository navigation
shared/apm.md checkout step fails in private caller repos with metadata-only token #28672
Description
Summary
After updating a consumer workflow to a gh-aw release compiled with v0.71.1, the shared APM job now fails in a private caller repository before the agent starts.
The failure happens in the shared APM job's new checkout step:
Checkout workflow lock files
The token in that job only has metadata: read, so actions/checkout cannot fetch a private caller repo and fails with:
fatal: repository 'https://github.com/elastic/docs-content-internal/' not found
Repro context
Caller repo:
- private repo
elastic/docs-content-internal
Reusable workflow:
elastic/docs-actions/.github/workflows/gh-aw-docs-review.lock.yml@v1
Observed failing run:
Latest released docs-actions version used by the caller:
Actual failure
The failing job is Run docs-review / apm.
The log shows:
GITHUB_TOKEN Permissions
Metadata: read
Then in Checkout workflow lock files:
fatal: repository 'https://github.com/elastic/docs-content-internal/' not found
The process '/usr/bin/git' failed with exit code 128
This repeats across retries and the workflow stops before the agent job can run.
Why this seems new
This failure appears after moving to a gh-aw release line that includes the newer shared APM behavior.
In the Run docs-review / apm job, the shared workflow now includes a checkout step before packing APM packages. That step requires actual repository content access, but the job permissions are still effectively too weak for a private repo checkout.
Expected behavior
If the shared APM job needs to checkout workflow lock files from the caller repository, it should run with sufficient read permission to do so in private repos.
At minimum, private callers should not fail with a misleading repository not found when the actual problem is insufficient token scope for checkout.
Suspected fix direction
The shared APM job likely needs contents: read when Checkout workflow lock files is present.
If there is a reason to keep the job permissions narrow, another option would be to avoid the checkout entirely when it is not strictly required, or use a different mechanism that does not depend on repository contents access.
Notes
This is separate from the earlier PR-context skill-availability investigation. In this case, the workflow fails before the agent can even attempt to invoke any imported skill.
Activity
theletterf commentedon Apr 27, 2026
Additional finding after tracing the generated workflow and recent releases:
This private-repo regression appears very likely to have been introduced by the new APM bundle cache/lockfile optimization shipped in
v0.71.1, specifically:feat: use actions/cache and artifacts for APM bundle with lock file hash + engine ID keyWhy this looks like the culprit:
What changed in the failing job
In the failing private-repo run, the
Run docs-review / apmjob now contains new APM-related steps such as:Checkout workflow lock filesRestore APM bundle from cacheSave APM bundle to cacheThe failure happens in the first of those:
At the same time, the job reports only:
So the new APM flow is trying to read repository contents in a private caller repo, but the token in the
apmjob does not havecontents: read.Why this is separate from the earlier skill-clobbering bug
The earlier PR-context skill problem was about APM-restored
.github/skillsbeing overwritten later in the PR workflow. That was addressed in thev0.71.xline.This new regression is different:
apmjob,Release context
v0.71.1release notes explicitly mention the new APM caching feature:Relevant line from the notes:
feat: use actions/cache and artifacts for APM bundle with lock file hash + engine ID key(#28333)That lines up closely with the newly appearing steps in the failing
apmjob.Likely fix direction
If
Checkout workflow lock filesis required for the new cache-key logic, theapmjob likely needscontents: readin addition to the current effective metadata-only token.Alternative fix directions could be:
Bump gh-aw to v0.71.4 and drop substitution-syntax workaround (#126)
Revert gh-aw pin from v0.71.4 back to v0.71.1 (#128)