Propagate integration-test model credentials to issue-triage repro#5443
Conversation
Scopes the triage job to the integration GitHub Environment, adds the azure/login OIDC step, and exposes the same OpenAI / Azure OpenAI / Foundry / Anthropic env vars the integration test workflow uses. This lets the triage agent write repro code that constructs model clients from the environment without any secrets entering the agent prompt or generated-code literals. Azure OpenAI and Foundry continue to authenticate via AAD (DefaultAzureCredential), so there is no API key to leak for those providers.
There was a problem hiding this comment.
Pull request overview
Extends the Issue Triage GitHub Actions workflow so the “Reproduce reported issue” step can run generated Python against real model providers using the same environment-scoped credentials used by the integration test workflows.
Changes:
- Adds
id-token: writepermission and scopes thetriagejob to theintegrationGitHub Environment. - Adds an
azure/login@v2OIDC step to establish Azure authentication for Azure OpenAI / Foundry viaDefaultAzureCredential. - Injects model provider environment variables (OpenAI, Azure OpenAI, Foundry, Anthropic) into the repro step.
| - name: Azure CLI Login | ||
| uses: azure/login@v2 | ||
| with: | ||
| client-id: ${{ secrets.AZURE_CLIENT_ID }} | ||
| tenant-id: ${{ secrets.AZURE_TENANT_ID }} | ||
| subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} | ||
|
|
There was a problem hiding this comment.
The Azure CLI login runs before the spam gate and will execute even when the spam gate later blocks. Since Azure auth is only needed for the repro step, gate this step on the spam decision (and/or move it to just before "Reproduce reported issue") to avoid establishing an Azure session unnecessarily and to keep pre-repro execution as low-privilege as possible.
| FOUNDRY_PROJECT_ENDPOINT: ${{ vars.FOUNDRY_PROJECT_ENDPOINT }} | ||
| FOUNDRY_MODEL: ${{ vars.FOUNDRY_MODEL }} | ||
| FOUNDRY_AGENT_NAME: ${{ vars.FOUNDRY_AGENT_NAME }} | ||
| FOUNDRY_AGENT_VERSION: ${{ vars.FOUNDRY_AGENT_VERSION }} | ||
| FOUNDRY_MODELS_ENDPOINT: ${{ vars.FOUNDRY_MODELS_ENDPOINT || '' }} | ||
| FOUNDRY_MODELS_API_KEY: ${{ secrets.FOUNDRY_MODELS_API_KEY || '' }} | ||
| FOUNDRY_EMBEDDING_MODEL: ${{ vars.FOUNDRY_EMBEDDING_MODEL || '' }} | ||
| ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} | ||
| ANTHROPIC_CHAT_MODEL: ${{ vars.ANTHROPIC_CHAT_MODEL_ID }} |
There was a problem hiding this comment.
The PR description says the repro step env vars mirror python-integration-tests.yml, but the Foundry set is missing FOUNDRY_IMAGE_EMBEDDING_MODEL (present in the integration workflow). If repro code ever exercises image embedding via Foundry, this will fail; either add the missing variable here or update the description to reflect the intended subset.
| permissions: | ||
| contents: read | ||
| issues: write | ||
| id-token: write |
There was a problem hiding this comment.
id-token: write is granted at the workflow level, which also applies to the team_check job even though it doesn't use OIDC. For least-privilege, consider moving id-token: write to jobs.triage.permissions (or only the job(s) that call azure/login) and keeping workflow-level permissions minimal.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Automated Code Review
Reviewers: 4 | Confidence: 91%
✓ Correctness
This PR adds Azure OIDC authentication and model-provider environment variables to the issue triage workflow. The changes are structurally correct:
id-token: writeis required for theazure/login@v2OIDC flow, theenvironment: integrationgrants access to environment-scoped secrets/variables, and the env vars are properly scoped to the repro step. No correctness bugs found.
✓ Security Reliability
This PR adds Azure OIDC login and model-provider credentials to the issue-triage workflow for the repro step. The OIDC pattern (azure/login@v2 with federated credentials) is the recommended approach. The
environment: integrationgate is a good security control. The workflow currently triggers only onworkflow_dispatch, meaning a privileged user must manually invoke it, which limits exposure. One minor improvement: theid-token: writepermission is granted at workflow level, giving it to theteam_checkjob which doesn't need it—scoping it to thetriagejob would follow least-privilege. The multiple API keys (OpenAI, Anthropic, Foundry) are passed as environment variables to a step that ultimately processes user-authored issue content for repro; the DevFlow scripts are in a private repo so the sanitization boundary cannot be verified here, but the layered controls (manual trigger, environment protection, spam gate) provide reasonable defense in depth.
✓ Test Coverage
This PR modifies a GitHub Actions workflow file (.github/workflows/issue-triage.yml) to add Azure OIDC login and model-provider environment variables for the issue triage pipeline. These are CI/CD infrastructure changes — workflow YAML files are not covered by unit tests in this repository. The scripts they invoke (classify_issue_spam.py, trigger_issue_repro.py) reside in a private devflow repo and are outside the scope of this PR. No application code or testable logic was added or changed in this repository, so there is no missing test coverage to flag.
✗ Design Approach
This change widens the trust boundary of issue triage in two important ways. First, it binds the whole triage job to the privileged
integrationenvironment and performs Azure login before the existing spam gate, so every non-team issue—including ones later rejected as spam—now gets access to environment-backed credentials and an Azure identity. Second, the repro step now exports a broad set of model-provider secrets into the environment specifically for generated repro code to consume, which is a much broader exposure than selecting a single provider through trusted workflow logic.
Flagged Issues
- The repro step injects all configured provider credentials into the generated reproduction environment, coupling issue-driven code execution to the full secret set instead of the minimum provider actually needed.
Suggestions
- Replace the broad secret injection with trusted provider selection outside the generated repro code, then pass only the single credential set required for that run.
Automated review by moonbox3's agents
Summary
Extends the
Issue Triageworkflow so the reproduce step can execute generated Python that calls a real language model, using the same credentials already proven in the integration test workflow — without those secrets ever entering the agent prompt.triagejob to theintegrationGitHub Environment and addid-token: writepermission.azure/login@v2OIDC step to establish an AAD session for Azure OpenAI and Foundry callers (DefaultAzureCredentialpicks this up automatically — no API key to leak).Reproduce reported issuestep only, inject the OpenAI / Azure OpenAI / Foundry / Anthropic env vars (keys fromsecrets, model ids/endpoints fromvars) that mirrorpython-integration-tests.yml. The spam-gate step keeps its minimal environment.A companion change in
moonbox3/agent-dashboard@mainupdatesrepro_instructionsso the agent must construct clients from env-based constructors and must never print/log secrets or inline credentials as literals.Test plan
workflow_dispatchagainst a known-good bug issue and confirm theintegrationenvironment's reviewer gate appears before execution.Azure CLI Loginstep succeeds and theReproduce reported issuejob has the expected env vars.