Scenario
We are enabling automatic documentation checks for PRs merged into dotnet/aspnetcore:main. The agent workflow reads the merged source PR, checks out dotnet/AspNetCore.Docs:main, and publishes documentation changes through configured safe outputs.
The desired direct trigger is:
on:
pull_request_target:
types: [closed]
branches: [main]
if: github.event.pull_request.merged == true
The workflow and helpers come from the base repository. The documentation checkout is configured independently of the PR payload; source PR changes are read as data rather than checked out and executed.
Manual workflow_dispatch already works with our docs GitHub App credentials and Copilot PAT configuration. Ordinary pull_request events do not normally receive the required repository secrets for fork PRs, so they are not an equivalent replacement.
Current behavior
Our pinned gh-aw v0.89.21 has two constraints:
- Strict compilation rejects a fixed external repository checkout under
pull_request_target. The validator accepts only an omitted repository or ${{ github.repository }}, with an omitted ref or the supported PR base-ref/base-SHA expressions.
- Strict mode emits a warning for every
pull_request_target workflow, including checkout: false and accepted base-repository checkouts. This is separate from the checkout error, but prevents our zero-warning validation gate.
We inspected the v0.89.21 validator, its tests, and the current main implementation. At the time of inspection, main retained both behaviors.
This appears to be an intentional policy limitation rather than a trigger-parsing bug.
Illustrative configuration
This abbreviated example shows the desired trigger and checkout shape, not a complete runnable workflow:
on:
pull_request_target:
types: [closed]
branches: [main]
if: github.event.pull_request.merged == true
checkout:
- repository: dotnet/AspNetCore.Docs
ref: main
path: .
current: true
Our actual checkout also supplies configured GitHub App authentication. Neither its repository nor its ref comes from the PR head.
Requested capability
Could gh-aw support an explicit, narrowly scoped policy or mode for this scenario while retaining strict validation elsewhere?
The capability would:
- Permit explicitly declared external repository/ref checkouts—for example, through a literal repository/ref allowlist or another maintainers-selected mechanism.
- Provide a trigger-specific acknowledgment of the unconditional warning, without requiring
strict: false or suppressing unrelated diagnostics.
- Retain validation for configurations outside the declared policy, including unsupported PR-dependent repository/ref expressions.
- Include compiler regressions for accepted and rejected checkout configurations and warning behavior.
We are not requesting removal of the existing validation globally. The exact configuration design is open to maintainers’ recommendations.
Current workaround
dotnet/aspnetcore#69694 implements a small ordinary Actions dispatcher:
PR merged into main
→ pull_request_target dispatcher
→ workflow_dispatch of the agent workflow at main
This preserves strict compilation and the existing authentication/checkout configuration, but produces two workflow runs and requires explicit bot-dispatch authorization.
Supporting the direct trigger would let us remove that bridge and keep event handling, context preparation, and documentation analysis in one workflow.
Validation boundary
The direct-trigger compilation failure was observed locally with v0.89.21. The dispatcher-based implementation passed strict compilation with zero warnings.
No live direct-trigger run was performed. Runtime event handling and publication would need separate validation once this configuration is supported.
Scenario
We are enabling automatic documentation checks for PRs merged into
dotnet/aspnetcore:main. The agent workflow reads the merged source PR, checks outdotnet/AspNetCore.Docs:main, and publishes documentation changes through configured safe outputs.The desired direct trigger is:
The workflow and helpers come from the base repository. The documentation checkout is configured independently of the PR payload; source PR changes are read as data rather than checked out and executed.
Manual
workflow_dispatchalready works with our docs GitHub App credentials and Copilot PAT configuration. Ordinarypull_requestevents do not normally receive the required repository secrets for fork PRs, so they are not an equivalent replacement.Current behavior
Our pinned gh-aw v0.89.21 has two constraints:
pull_request_target. The validator accepts only an omitted repository or${{ github.repository }}, with an omitted ref or the supported PR base-ref/base-SHA expressions.pull_request_targetworkflow, includingcheckout: falseand accepted base-repository checkouts. This is separate from the checkout error, but prevents our zero-warning validation gate.We inspected the v0.89.21 validator, its tests, and the current main implementation. At the time of inspection,
mainretained both behaviors.This appears to be an intentional policy limitation rather than a trigger-parsing bug.
Illustrative configuration
This abbreviated example shows the desired trigger and checkout shape, not a complete runnable workflow:
Our actual checkout also supplies configured GitHub App authentication. Neither its repository nor its ref comes from the PR head.
Requested capability
Could gh-aw support an explicit, narrowly scoped policy or mode for this scenario while retaining strict validation elsewhere?
The capability would:
strict: falseor suppressing unrelated diagnostics.We are not requesting removal of the existing validation globally. The exact configuration design is open to maintainers’ recommendations.
Current workaround
dotnet/aspnetcore#69694 implements a small ordinary Actions dispatcher:
This preserves strict compilation and the existing authentication/checkout configuration, but produces two workflow runs and requires explicit bot-dispatch authorization.
Supporting the direct trigger would let us remove that bridge and keep event handling, context preparation, and documentation analysis in one workflow.
Validation boundary
The direct-trigger compilation failure was observed locally with v0.89.21. The dispatcher-based implementation passed strict compilation with zero warnings.
No live direct-trigger run was performed. Runtime event handling and publication would need separate validation once this configuration is supported.