Configure a shared gh-aw Copilot model variable for dotnet/sdk workflows

[nagilson]

Summary

The dotnet/sdk gh-aw workflows already support shared model selection through GitHub Actions variables, but the repository does not currently appear to define one. We should configure a repo-level or org-level model variable instead of hardcoding a model in individual workflow source files.

Recommended starting point:

GH_AW_DEFAULT_MODEL_COPILOT=any

If we need separate behavior by phase, gh-aw also supports:

GH_AW_MODEL_AGENT_COPILOT=<agent model alias>
GH_AW_MODEL_DETECTION_COPILOT=<detection model alias>

Why

Recent PR feedback on #55244 pointed out that hardcoding a model in a workflow source file creates churn and cost/availability risk when supported model names change. The generated gh-aw lock files already provide a better central control point via Actions variables, so model selection should happen through repo/org configuration.

This lets us share one model choice across the gh-aw workflows without repeatedly editing workflow YAML.

Current evidence

The checked-in gh-aw source workflow for issue triage uses only:

engine: copilot

The generated locks already read model configuration from variables:

COPILOT_MODEL: ${{ vars.GH_AW_MODEL_AGENT_COPILOT || vars.GH_AW_DEFAULT_MODEL_COPILOT || 'claude-sonnet-4.6' }}

and for detection:

COPILOT_MODEL: ${{ vars.GH_AW_MODEL_DETECTION_COPILOT || vars.GH_AW_DEFAULT_MODEL_COPILOT || 'claude-sonnet-4.6' }}

These are present in both current gh-aw lock files:

• .github/workflows/issue-triage.lock.yml
• .github/workflows/add-tactics-template-on-comment.lock.yml

Repository variable check for dotnet/sdk found only these Copilot-related variables:

COPILOT_AGENT_FIREWALL_ALLOW_LIST_ADDITIONS=vsblob.vsassets.io
COPILOT_AGENT_FIREWALL_ENABLED=true

No repo-level GH_AW_DEFAULT_MODEL_COPILOT, GH_AW_MODEL_AGENT_COPILOT, or GH_AW_MODEL_DETECTION_COPILOT was found. I could not inspect dotnet org-level variables because GitHub returned HTTP 403 for org Actions variables.

Empirical model results

The current locked gh-aw runtime for issue-triage.lock.yml is:

gh-aw compiler: v0.81.6
Copilot CLI: 1.0.65
AWF/firewall: 0.27.11

The lock's model map includes these agent aliases:

sonnet-6x
gpt-5.5
gpt-5.4
gpt-5.3
gemini-pro
any

It does not include gpt-5.6, gpt-5.6-luna, or luna.

Observed failures:

[ERROR] Error: model 'gpt-5.6-luna?effort=high' is retired or unsupported.

and in a follow-up variable-based test on nagilson/sdk run 29605842281:

COPILOT_MODEL: gpt-5.5?effort=high
[ERROR] Error: model 'gpt-5.5?effort=high' is retired or unsupported.

The temporary fork variable used for that test was removed afterward.

Important distinction: the model alias spec supports URL-style parameters like ?effort=high, but this locked runtime still rejected the full gpt-5.5?effort=high string. The current repo should therefore prefer a supported alias without parameters unless/until the locked gh-aw/AWF version is updated and validated.

Proposed change

Configure one shared Actions variable for gh-aw model selection:

GH_AW_DEFAULT_MODEL_COPILOT=any

Alternative if we want to pin only the agent phase while leaving detection at the generated default:

GH_AW_MODEL_AGENT_COPILOT=any

Avoid adding model: to individual gh-aw source files unless there is a workflow-specific requirement.

Acceptance criteria

• dotnet/sdk has a repo-level or org-level gh-aw model variable configured.
• Existing gh-aw workflows continue to compile from source without hardcoded model churn.
• A manually dispatched issue-triage.lock.yml run succeeds past the Copilot CLI model validation step.
• The selected value is one of the aliases supported by the checked-in lock/runtime, such as any, unless a newer gh-aw/AWF lock is generated and validated.

Follow-up considerations

• If the org wants this across multiple dotnet repositories, prefer an org-level variable over per-repo variables.
• Native GitHub Copilot PR reviews do not appear to use these gh-aw variables from this repository. This issue is specifically about gh-aw workflows.
• Custom checked-in agents may still have independent model fields, for example .github/agents/static-web-assets-agent.agent.md currently declares its own model.