Summary
Two gh-aw v0.71.5 issues hit during real-world wiring of a pull_request_target review-panel workflow at hackathon-white-pig-8/zava-storefront. Both blocked the run before the agent started; both have local workarounds. Filing for upstream visibility.
Repro context
- gh-aw
v0.71.5
- Engine:
copilot (claude-sonnet-4.6)
- Workflow uses
microsoft/apm-action@v1.6.0 to install APM bundles
- Workflow source:
pr-review-panel.md
Issue 1 — checkout: false is incompatible with PR-context triggers
When checkout: false is set under any PR trigger (pull_request or pull_request_target), the compiler still emits a Checkout PR branch step in the agent job. That step runs checkout_pr_branch.cjs via actions/github-script, which executes git fetch / git rev-parse against the runner's working directory — but with checkout: false, no actions/checkout ran, so there is no .git and the helper aborts:
fatal: not a git repository (or any of the parent directories): .git
##[error]Event type: pull_request
##[error]PR number: 3
##[error]Error message: The process '/usr/bin/git' failed with exit code 128
##[error]Attempted to check out: test/panel-smoke
##[error]ERR_API: Failed to checkout PR branch: The process '/usr/bin/git' failed with exit code 128
Failing run (pull_request): https://github.com/hackathon-white-pig-8/zava-storefront/actions/runs/25479961077
Workaround: remove checkout: false. After removal the next run was fully green: https://github.com/hackathon-white-pig-8/zava-storefront/actions/runs/25480109686.
Suggested fix: when checkout: false is in frontmatter and the trigger is PR-context, either (a) skip the Checkout PR branch helper step entirely in the compiled lock yml, or (b) emit a fast-fail at compile time so users learn this isn't a supported combination before they ship.
Issue 2 — pull_request_target × microsoft/apm-action wipes .git before the helper runs
Independent of Issue 1: with pull_request_target and checkout: true (default), the lock yml correctly emits an actions/checkout (sparse) step early in the agent job, which DOES create .git. But by the time the Checkout PR branch helper runs (after the microsoft/apm-action@v1.6.0 step that installs bundles), .git is gone and the same fatal: not a git repository error fires.
Failing run (pull_request_target): https://github.com/hackathon-white-pig-8/zava-storefront/actions/runs/25479764768
I have not yet root-caused which step wipes .git — it's somewhere between the sparse-checkout step (lock line ~152) and the Checkout PR branch helper (lock line ~434). Strong suspicion is microsoft/apm-action (line ~430) altering the workspace, but it could be one of the intervening agent-config save/restore steps.
Workaround: switch the workflow trigger from pull_request_target to pull_request. This loses fork-safety but is acceptable in a workshop / same-org context where label application requires repo write.
Suggested investigation: repro inside gh aw test fixtures with microsoft/apm-action enabled, isolate the step that wipes .git, and either preserve the workspace or have the helper re-actions/checkout lazily before its git operations.
Why both matter together
Anyone vendoring a pull_request_target review-panel workflow alongside microsoft/apm-action (the canonical pattern for fork-safe agentic CI) currently can't ship: Issue 2 forces them off _target, and if they try checkout: false as a defensive measure on the way to pull_request, Issue 1 catches them. The combination meant ~3 hours of debugging across 4 failed runs before we got to green.
Reference
- Local fix PRs: #4 (trigger swap), #5 (remove
checkout: false)
- Smoke green: run 25480109686, advisory comment posted on PR #3
Happy to bring more repro detail or test against a fix candidate.
Summary
Two gh-aw v0.71.5 issues hit during real-world wiring of a
pull_request_targetreview-panel workflow athackathon-white-pig-8/zava-storefront. Both blocked the run before the agent started; both have local workarounds. Filing for upstream visibility.Repro context
v0.71.5copilot(claude-sonnet-4.6)microsoft/apm-action@v1.6.0to install APM bundlespr-review-panel.mdIssue 1 —
checkout: falseis incompatible with PR-context triggersWhen
checkout: falseis set under any PR trigger (pull_requestorpull_request_target), the compiler still emits aCheckout PR branchstep in the agent job. That step runscheckout_pr_branch.cjsviaactions/github-script, which executesgit fetch/git rev-parseagainst the runner's working directory — but withcheckout: false, noactions/checkoutran, so there is no.gitand the helper aborts:Failing run (pull_request): https://github.com/hackathon-white-pig-8/zava-storefront/actions/runs/25479961077
Workaround: remove
checkout: false. After removal the next run was fully green: https://github.com/hackathon-white-pig-8/zava-storefront/actions/runs/25480109686.Suggested fix: when
checkout: falseis in frontmatter and the trigger is PR-context, either (a) skip theCheckout PR branchhelper step entirely in the compiled lock yml, or (b) emit a fast-fail at compile time so users learn this isn't a supported combination before they ship.Issue 2 —
pull_request_target×microsoft/apm-actionwipes.gitbefore the helper runsIndependent of Issue 1: with
pull_request_targetandcheckout: true(default), the lock yml correctly emits anactions/checkout(sparse) step early in the agent job, which DOES create.git. But by the time theCheckout PR branchhelper runs (after themicrosoft/apm-action@v1.6.0step that installs bundles),.gitis gone and the samefatal: not a git repositoryerror fires.Failing run (pull_request_target): https://github.com/hackathon-white-pig-8/zava-storefront/actions/runs/25479764768
I have not yet root-caused which step wipes
.git— it's somewhere between the sparse-checkout step (lock line ~152) and the Checkout PR branch helper (lock line ~434). Strong suspicion ismicrosoft/apm-action(line ~430) altering the workspace, but it could be one of the intervening agent-config save/restore steps.Workaround: switch the workflow trigger from
pull_request_targettopull_request. This loses fork-safety but is acceptable in a workshop / same-org context where label application requires repo write.Suggested investigation: repro inside
gh awtest fixtures withmicrosoft/apm-actionenabled, isolate the step that wipes.git, and either preserve the workspace or have the helper re-actions/checkoutlazily before its git operations.Why both matter together
Anyone vendoring a
pull_request_targetreview-panel workflow alongsidemicrosoft/apm-action(the canonical pattern for fork-safe agentic CI) currently can't ship: Issue 2 forces them off_target, and if they trycheckout: falseas a defensive measure on the way topull_request, Issue 1 catches them. The combination meant ~3 hours of debugging across 4 failed runs before we got to green.Reference
checkout: false)Happy to bring more repro detail or test against a fix candidate.