shared/apm.md checkout step fails in private caller repos with metadata-only token

[theletterf]

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:

• https://github.com/elastic/docs-content-internal/actions/runs/24982944489/job/73149298357

Latest released docs-actions version used by the caller:

• 1.12.2
• https://github.com/elastic/docs-actions/releases

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.

[theletterf]

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:

• #28333 — feat: use actions/cache and artifacts for APM bundle with lock file hash + engine ID key

Why this looks like the culprit:

What changed in the failing job

In the failing private-repo run, the Run docs-review / apm job now contains new APM-related steps such as:

• Checkout workflow lock files
• Restore APM bundle from cache
• Save APM bundle to cache

The failure happens in the first of those:

fatal: repository 'https://github.com/elastic/docs-content-internal/' not found

At the same time, the job reports only:

GITHUB_TOKEN Permissions
Metadata: read

So the new APM flow is trying to read repository contents in a private caller repo, but the token in the apm job does not have contents: read.

Why this is separate from the earlier skill-clobbering bug

The earlier PR-context skill problem was about APM-restored .github/skills being overwritten later in the PR workflow. That was addressed in the v0.71.x line.

This new regression is different:

• the workflow now fails earlier in the dedicated apm job,
• before the agent starts,
• because the new lockfile/cache checkout path cannot access the private caller repository.

Release context

v0.71.1 release notes explicitly mention the new APM caching feature:

• https://github.com/github/gh-aw/releases/tag/v0.71.1

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 apm job.

Likely fix direction

If Checkout workflow lock files is required for the new cache-key logic, the apm job likely needs contents: read in addition to the current effective metadata-only token.

Alternative fix directions could be:

• avoid checkout in private callers when not strictly necessary,
• derive the cache key from already-available workflow artifacts instead of repository checkout,
• or gate the checkout/cache optimization behind repository accessibility and fall back cleanly.