Add allowed-repos support to add-labels and close-issue safe outputs

[Copilot]

Fix allowed-repos for add-labels and close-issue Safe Outputs ✅

Summary

Fixed the issue where allowed-repos field was not working for add-labels and close-issue safe outputs (it only worked for add-comment). The fix enables cross-repository operations for these safe output types. Additionally fixed add_comment config generation to properly wire through the allowed-repos field.

Root Cause

Schema Validation Gap:

• ✅ add-comment had allowed-repos in JSON schema
• ❌ add-labels missing allowed-repos in JSON schema
• ❌ close-issue missing allowed-repos in JSON schema

Backend Already Supported It:

• JavaScript handlers (add_labels.cjs, close_issue.cjs) already used resolveTargetRepoConfig(config) to read allowed_repos
• Go types already had SafeOutputTargetConfig with AllowedRepos []string field
• Config generation was NOT wiring the field through to handlers (including add_comment)

Why Imports Worked But Inline Failed:

• Schema validation only applies to direct frontmatter fields
• Shared imports bypass inline schema validation
• Fields passed through to handlers but were silently ignored in config generation

Changes Made

1. Schema Updates:

• Added allowed-repos array field to add-labels schema with description
• Added allowed-repos array field to close-issue schema with description
• Both match the format used in add-comment schema

2. Config Generation Enhancement:

• Created generateTargetConfigWithRepos() helper function that includes:
  • target field (issue/PR targeting)
  • target-repo field (cross-repo slug)
  • allowed_repos field (additional allowed repos)
• Updated add_labels config generation to use new helper
• Updated close_issue config generation to use new helper
• Updated add_comment config generation to use new helper (fixes allowed_repos not being wired through)
• Documented naming convention differences (target-repo vs allowed_repos)

3. Smoke Test Integration:

• Added allowed-repos: ["github/gh-aw"] to smoke-copilot workflow for add-labels
• Added allowed-repos: ["github/gh-aw"] to smoke-copilot workflow for add-comment
• Tests cross-repository functionality in smoke tests

4. Complete Validation:

• Schema changes formatted with prettier
• Binary rebuilt to embed updated schema
• All workflows recompiled successfully
• Unit tests pass (all packages)
• JavaScript tests pass (repo_helpers, add_labels, close_issue)
• Code review feedback addressed
• Security scan clean (0 alerts)
• Merged with main branch

Testing Evidence

Test Workflow:

safe-outputs:
  add-labels:
    target: "*"
    max: 1
    allowed-repos:
      - "microsoft/vscode"
  close-issue:
    target: "*"
    max: 1
    allowed-repos:
      - "microsoft/vscode"
  add-comment:
    max: 2
    allowed-repos:
      - "github/gh-aw"

Before Fix: Compilation error for inline allowed-repos

error: Unknown property: allowed-repos. Valid fields are: allowed, github-token, max, target, target-repo

After Fix: ✅ Compiles successfully

{
  "add_labels": {
    "allowed_repos": ["microsoft/vscode"],
    "max": 1,
    "target": "*"
  },
  "close_issue": {
    "allowed_repos": ["microsoft/vscode"],
    "max": 1,
    "target": "*"
  },
  "add_comment": {
    "allowed_repos": ["github/gh-aw"],
    "max": 2
  }
}

Test Coverage:

• repo_helpers.test.cjs: 35 tests for repository operations including allowed-repos scenarios
• add_labels.test.cjs: 21 tests including cross-repo scenarios with allowed-repos
• close_issue.test.cjs: 17 tests including cross-repo scenarios with allowed-repos
• smoke-copilot.md: Integration test for cross-repo functionality with add-labels and add-comment

Impact

Workflows Affected:

• 4 workflows regenerated with improved config:
  • .github/workflows/ai-moderator.lock.yml (added target field)
  • .github/workflows/dependabot-go-checker.lock.yml (added target field)
  • .github/workflows/semantic-function-refactor.lock.yml (added target field)
  • .github/workflows/smoke-copilot.lock.yml (added allowed_repos for add-labels and add-comment)

No Breaking Changes:

• Existing workflows without allowed-repos continue to work
• New field is optional and backward compatible
• Config generation correctly handles both with and without allowed-repos

---

✅ Ready for merge - All validations pass, no security issues, backward compatible, comprehensive test coverage

Original prompt

---

This section details on the original issue you should resolve

<issue_title>allowed-repos does not work for add-labels and close-issue safe outputs (works for add-comment)</issue_title>
<issue_description>🤖: Bug report submitted by AI

Summary

allowed-repos does not work for add-labels and close-issue safe outputs when imported via a shared workflow file. It works correctly for add-comment.

Additionally, allowed-repos as an inline field on add-labels or close-issue throws a compilation error, but the same field in a shared import file compiles without error — suggesting the compiler accepts it in imports but doesn't properly wire it through at runtime.

Reproduction

Setup

A shared import file at .github/workflows/shared/allowed-repos.md:

---
safe-outputs:
  close-issue:
    allowed-repos:
      - "microsoft/vscode"
  add-labels:
    allowed-repos:
      - "microsoft/vscode"
  add-comment:
    allowed-repos:
      - "microsoft/vscode"
  dispatch-workflow:
    workflows: [issue-hygiene, issue-validator, stale-triage]
    allowed-repos:
      - "microsoft/vscode"
---

A workflow that imports it:

---
imports:
  - shared/allowed-repos.md
safe-outputs:
  add-labels:
    target: "*"
    max: 1
  close-issue:
    target: "*"
    max: 1
  add-comment:
    target: "*"
    max: 1
---

Observed Behavior

1. add-comment with allowed-repos: Works correctly cross-repo ✅ (Note: have not yet confirmed the action is taken, but it does compile)
2. add-labels with allowed-repos: Does NOT work cross-repo ❌
3. close-issue with allowed-repos: Does NOT work cross-repo ❌

Inline vs Import Inconsistency

When allowed-repos is written inline on add-labels, the compiler rejects it:

error: Unknown property: allowed-repos. Valid fields are: allowed, github-token, max, target, target-repo

But when the same allowed-repos is in a shared import file, it compiles without error — yet doesn't function at runtime.

This suggests:

• The compiler's inline schema validation doesn't list allowed-repos as valid for add-labels / close-issue
• The shared import path bypasses this validation
• Either the field should be accepted inline too (and wired through), or the shared import should also reject it with an error instead of silently accepting and not working

Expected Behavior

allowed-repos should work consistently for all safe output types — either:

• Accept it for all safe outputs (inline and import) and wire it through at runtime, OR
• Reject it at compile time if not supported

Environment

• gh-aw version: v0.43.9
• Repository: benvillalobos/gh-aw-test

Related

• close_issue and add_labels safe output handlers do not support target-repo for cross-repository operations #15027 — close_issue and add_labels handler cross-repo fix (resolved, but allowed-repos path may not have been covered)
• remove_labels and assign_to_user safe output handlers do not support target-repo for cross-repository operations #15216 — remove_labels and assign_to_user handlers missing cross-repo support</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes allowed-repos does not work for add-labels and close-issue safe outputs (works for add-comment) #15238

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[pelikhan]

@copilot refactor allowed-repos logic into helper into separate .cjs files. Add tests

[pelikhan]

@copilot merge main and recompile

[Copilot]

@copilot refactor allowed-repos logic into helper into separate .cjs files. Add tests

I'll refactor the allowed-repos logic into a dedicated helper file. Currently, the logic is well-organized in repo_helpers.cjs with comprehensive tests already in place:

Current structure:

• repo_helpers.cjs contains: parseAllowedRepos(), resolveTargetRepoConfig(), validateRepo(), resolveAndValidateRepo()
• Tests exist in: repo_helpers.test.cjs (345 lines), add_labels.test.cjs, and close_issue.test.cjs

Refactoring plan:

1. Extract allowed-repos specific logic into allowed_repos_helpers.cjs
2. Keep general repo parsing functions in repo_helpers.cjs
3. Ensure existing tests continue to pass
4. Add any missing test coverage for edge cases

Will implement this refactoring now.

[pelikhan]

@copilot revert commit cee7f9a

[Copilot]

@copilot merge main and recompile

Merged main (already up-to-date) and recompiled all 147 workflows successfully. Commit: 4cd404f

@copilot revert commit cee7f9a

Reverted commit cee7f9a (refactoring commit). The allowed-repos logic remains in repo_helpers.cjs with existing test coverage. Commit: 4cd404f

[pelikhan]

@copilot add allowed-repos: ["github/gh-aw"] in smoke copilot for add-labels, add-comment

[Copilot]

@copilot add allowed-repos: ["github/gh-aw"] in smoke copilot for add-labels, add-comment

Added allowed-repos: ["github/gh-aw"] to both add-labels and add-comment in smoke-copilot.md. Also fixed add_comment config generation to properly wire through allowed-repos field. Commit: ff48bec

Verified config.json output:

{
  "add_comment": {
    "allowed_repos": ["github/gh-aw"],
    "max": 2
  },
  "add_labels": {
    "allowed": ["smoke-copilot"],
    "allowed_repos": ["github/gh-aw"],
    "max": 3
  }
}

[Copilot]

Pull request overview

This PR fixes the allowed-repos field support for add-labels and close-issue safe outputs, enabling cross-repository operations for these output types. The root cause was a schema validation gap where allowed-repos was missing from the JSON schema for these output types, even though the JavaScript handlers and Go types already supported it.

Changes:

• Added allowed-repos field to JSON schemas for close-issue and add-labels output types
• Created generateTargetConfigWithRepos() helper function to consolidate config generation logic across add_comment, close_issue, and add_labels
• Updated smoke test workflow to verify cross-repository functionality

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
pkg/workflow/safe_outputs_config_generation_helpers.go	New helper function generateTargetConfigWithRepos() that handles target, target-repo, and allowed_repos fields with documented naming convention (hyphen vs underscore)
pkg/workflow/safe_outputs_config_generation.go	Updated config generation for add_comment, close_issue, and add_labels to use the new helper function, properly wiring through allowed_repos
pkg/parser/schemas/main_workflow_schema.json	Added allowed-repos array field to close-issue and add-labels schemas with consistent descriptions matching add-comment
.github/workflows/smoke-copilot.md	Added allowed-repos: ["github/gh-aw"] to add-labels and add-comment for testing cross-repo functionality
.github/workflows/smoke-copilot.lock.yml	Regenerated lock file with allowed_repos in both MCP config and handler config, plus updated tool schemas with repo parameter
.github/workflows/semantic-function-refactor.lock.yml	Regenerated with target: "*" field added to close_issue config
.github/workflows/dependabot-go-checker.lock.yml	Regenerated with target: "*" field added to close_issue config
.github/workflows/ai-moderator.lock.yml	Regenerated with target: "*" field added to add_labels config

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The additionalFields map for add_comment is created but left empty. Consider adding hide_older_comments and allowed_reasons fields to maintain consistency with the handler config in compiler_safe_outputs_config.go (lines 132-137), which includes these fields.

While this is a pre-existing discrepancy (the old code also didn't include these fields), it would be beneficial to address it while refactoring this section. The JavaScript handler (add_comment.cjs) expects hide_older_comments in the config (line 278).

Example:

additionalFields := make(map[string]any)
if data.SafeOutputs.AddComments.HideOlderComments {
    additionalFields["hide_older_comments"] = true
}
if len(data.SafeOutputs.AddComments.AllowedReasons) > 0 {
    additionalFields["allowed_reasons"] = data.SafeOutputs.AddComments.AllowedReasons
}