[Code Quality] Reuse TemplatableBool for ContinueOnError and ReportFailureAsIssue fields instead of any

[github-actions]

Description

Two fields use any for a bool-or-templatable-expression shape that the codebase already has a named type for (TemplatableBool, defined at pkg/workflow/templatables.go:143):

1. WorkflowStep.ContinueOnError at pkg/workflow/step_types.go:28 - comment says "Can be bool or string expression"
2. SafeOutputsConfig.ReportFailureAsIssue at pkg/workflow/safe_outputs_config_types.go:109 - currently any; the []any categories case is already parsed separately into ReportFailureAsIssueCategories/ReportFailureAsIssueExcludedCategories, so this field only needs to represent bool-or-expression

Suggested Changes

• Change WorkflowStep.ContinueOnError type from any to *TemplatableBool
• Change SafeOutputsConfig.ReportFailureAsIssue type from any to *TemplatableBool
• Update the 3-arm type switch in pkg/workflow/notify_comment_conclusion_helpers.go:346 (bool/string/[]any) to use the TemplatableBool accessor instead of manual type assertion for the bool/string arms
• Update parsing code that populates these fields from YAML frontmatter

Files Affected

• pkg/workflow/step_types.go (line 28)
• pkg/workflow/safe_outputs_config_types.go (line 109)
• pkg/workflow/notify_comment_conclusion_helpers.go (line 346)
• pkg/workflow/templatables.go (reference type, no changes needed)

Success Criteria

• Both fields typed as *TemplatableBool
• Existing type-switch logic replaced with TemplatableBool methods
• All existing tests pass (including YAML parsing round-trip tests for these fields)

Source

Extracted from Typist: Go Type Consistency Analysis discussion #51058

Priority

Medium - removes a redundant runtime type switch and a class of assertion bugs

🔍 Task mining by Discussion Task Miner - Code Quality Improvement Agent · auto · 48.8 AIC · ⌖ 3.58 AIC · ⊞ 10.2K · ◷

• expires on Aug 8, 2026, 5:10 AM UTC-08:00