Problem
The safe outputs application logic in pkg/workflow/compiler_safe_outputs_steps.go is tightly coupled to event trigger context (e.g., github.base_ref, github.event.pull_request.base.ref). This was explicitly flagged as architectural debt by a developer with a TODO comment:
// TODO: `@dsyme` says: We must remove this. Indeed the important longer term
// thing is that we need the processing of the application of safe outputs
// to be independent of:
// * event trigger context
// * ideally repository context too
// So safe outputs are "self-describing" and already know which base branch,
// repository etc. they're targeting.
Location: pkg/workflow/compiler_safe_outputs_steps.go:67-73
Current Limitation
Because the safe outputs checkout step constructs complex fallback expressions (github.base_ref || github.event.pull_request.base.ref || github.ref_name || ...), there is a known limitation: for issue_comment events on PRs targeting non-default branches, the checkout falls back to the default branch instead of the actual PR base. The comment notes this is unavoidable given current constraints.
Impact
- Severity: Medium
- Risk: The tight event coupling makes this code harder to test in isolation, harder to extend to new event types, and creates subtle bugs for edge-case event triggers.
- Affected:
issue_comment events on PRs targeting non-default branches — safe outputs apply to the wrong base branch.
Recommendation
Refactor safe outputs to be "self-describing": embed enough context (target branch, repository) in the safe output payload itself so the application step does not need to reconstruct this from event payloads. This decouples the backend application from frontend (event-trigger) concerns and eliminates the edge case.
Approach:
- Enrich the safe output metadata to include
target_branch and target_repo at generation time (frontend)
- Update the application step to read these fields directly rather than inferring from event context
- The complex fallback expression can then be removed from
compiler_safe_outputs_steps.go
Validation
Estimated Effort: Large (architectural change touching both safe output generation and application)
Generated by Sergo — Run ID: §25301644786
Generated by Sergo - Serena Go Expert · ● 394.3K · ◷
Problem
The safe outputs application logic in
pkg/workflow/compiler_safe_outputs_steps.gois tightly coupled to event trigger context (e.g.,github.base_ref,github.event.pull_request.base.ref). This was explicitly flagged as architectural debt by a developer with a TODO comment:Location:
pkg/workflow/compiler_safe_outputs_steps.go:67-73Current Limitation
Because the safe outputs checkout step constructs complex fallback expressions (
github.base_ref || github.event.pull_request.base.ref || github.ref_name || ...), there is a known limitation: forissue_commentevents on PRs targeting non-default branches, the checkout falls back to the default branch instead of the actual PR base. The comment notes this is unavoidable given current constraints.Impact
issue_commentevents on PRs targeting non-default branches — safe outputs apply to the wrong base branch.Recommendation
Refactor safe outputs to be "self-describing": embed enough context (target branch, repository) in the safe output payload itself so the application step does not need to reconstruct this from event payloads. This decouples the backend application from frontend (event-trigger) concerns and eliminates the edge case.
Approach:
target_branchandtarget_repoat generation time (frontend)compiler_safe_outputs_steps.goValidation
issue_commentevents on non-default-branch PRsEstimated Effort: Large (architectural change touching both safe output generation and application)
Generated by Sergo — Run ID: §25301644786