-
Notifications
You must be signed in to change notification settings - Fork 495
Extract shared SafeOutputAllowBlockConfig across safe-output handlers #42322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
6ce08fa
715c51d
0d7b207
4077c35
efe8074
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,12 +8,11 @@ var assignToUserLog = logger.New("workflow:assign_to_user") | |
|
|
||
| // AssignToUserConfig holds configuration for assigning users to issues from agent output | ||
| type AssignToUserConfig struct { | ||
| BaseSafeOutputConfig `yaml:",inline"` | ||
| SafeOutputTargetConfig `yaml:",inline"` | ||
| SafeOutputFilterConfig `yaml:",inline"` | ||
| Allowed []string `yaml:"allowed,omitempty"` // Optional list of allowed usernames. If omitted, any users are allowed. | ||
| Blocked []string `yaml:"blocked,omitempty"` // Optional list of blocked usernames or patterns (e.g., "copilot", "*[bot]") | ||
| UnassignFirst *string `yaml:"unassign-first,omitempty"` // If true, unassign all current assignees before assigning new ones | ||
| BaseSafeOutputConfig `yaml:",inline"` | ||
| SafeOutputTargetConfig `yaml:",inline"` | ||
| SafeOutputFilterConfig `yaml:",inline"` | ||
| SafeOutputAllowBlockConfig `yaml:",inline"` | ||
| UnassignFirst *string `yaml:"unassign-first,omitempty"` // If true, unassign all current assignees before assigning new ones | ||
| } | ||
|
Comment on lines
10
to
16
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fixed in the latest commit — |
||
|
|
||
| // parseAssignToUserConfig handles assign-to-user configuration | ||
|
|
||
| Original file line number | Diff line number | Diff line change | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -26,6 +26,13 @@ type SafeOutputDiscussionFilterConfig struct { | |||||||||||
| RequiredCategory string `yaml:"required-category,omitempty"` // Required category for discussion operations | ||||||||||||
| } | ||||||||||||
|
|
||||||||||||
| // SafeOutputAllowBlockConfig contains common allow/block lists for safe output configurations. | ||||||||||||
| // Embed this in safe output config structs that support optional allowed/blocked value filters. | ||||||||||||
| type SafeOutputAllowBlockConfig struct { | ||||||||||||
| Allowed []string `yaml:"allowed,omitempty"` // Optional list of allowed values | ||||||||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Semantic docstrings lost in generalization: the shared 💡 What was lost
The generic comment doesn't convey: when the list is omitted vs. present, what the wildcard behavior is, whether labels are auto-created, or that the empty-string sentinel for clearing a type is allowed. This context should be preserved either by adding handler-specific doc on the embedding site or by enriching the shared struct comments. |
||||||||||||
| Blocked []string `yaml:"blocked,omitempty"` // Optional list of blocked patterns (supports glob patterns) | ||||||||||||
| } | ||||||||||||
|
|
||||||||||||
| // CloseJobConfig represents common configuration for close operations (close-issue, close-discussion, close-pull-request) | ||||||||||||
| type CloseJobConfig struct { | ||||||||||||
| SafeOutputTargetConfig `yaml:",inline"` | ||||||||||||
|
|
@@ -34,9 +41,8 @@ type CloseJobConfig struct { | |||||||||||
|
|
||||||||||||
| // ListJobConfig represents common configuration for list-based operations (add-labels, add-reviewer, assign-milestone) | ||||||||||||
| type ListJobConfig struct { | ||||||||||||
| SafeOutputTargetConfig `yaml:",inline"` | ||||||||||||
| Allowed []string `yaml:"allowed,omitempty"` // Optional list of allowed values | ||||||||||||
| Blocked []string `yaml:"blocked,omitempty"` // Optional list of blocked patterns (supports glob patterns) | ||||||||||||
| SafeOutputTargetConfig `yaml:",inline"` | ||||||||||||
| SafeOutputAllowBlockConfig `yaml:",inline"` | ||||||||||||
| } | ||||||||||||
|
|
||||||||||||
| // ParseTargetConfig parses target and target-repo fields from a config map. | ||||||||||||
|
|
||||||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Operator-critical side-effect stripped from documentation: the original
Allowedcomment noted that "Labels will be created if they don't already exist in the repository." — this is a write side-effect, not just a filter. The generic replacement says only "Optional list of allowed values" and conceals this completely.💡 Why this matters
For
add_labels,Allowedserves a dual role:Allowedwas pre-approved.A user adding a label pattern like
team-backendtoAllowedis implicitly authorizing the agent to create that label in the target repository. Without documentation at the struct definition site, this side-effect is invisible to anyone reading just the config struct. At minimum, the embedding struct or a comment at the field declaration site should note this behavior.