Skip to content

Support an explicit strict-mode policy for pull_request_target workflows with fixed external checkouts #66564

Description

@DeagleGross

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:

  1. 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.
  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions