Skip to content

refactor: decouple safe-outputs processing from event trigger context #30066

@github-actions

Description

@github-actions

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:

  1. Enrich the safe output metadata to include target_branch and target_repo at generation time (frontend)
  2. Update the application step to read these fields directly rather than inferring from event context
  3. The complex fallback expression can then be removed from compiler_safe_outputs_steps.go

Validation

  • Safe outputs apply correctly for issue_comment events on non-default-branch PRs
  • All existing safe output tests pass
  • No event-context expressions remain in the application step (only in the frontend)

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 ·

  • expires on May 11, 2026, 5:02 AM UTC

Metadata

Metadata

Labels

cookieIssue Monster Loves Cookies!sergo

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions