Skip to content

Add self-hosted runner support for PR Visual Recaps #2038

Description

@CheckPickerUpper

Problem

The PR Visual Recap workflow currently hardcodes ubuntu-latest for the gate and recap jobs. Private repositories can exhaust hosted Actions minutes even when they have an available machine that could run the workflow.

GitHub does not bill Actions minutes for self-hosted runners. An opt-in runner setting would allow those repositories to keep using visual recaps without increasing hosted-runner spend.

Proposal

Keep ubuntu-latest as the default. Add a repository or organization variable such as VISUAL_RECAP_RUNS_ON to select the workflow runner.

The value could be JSON, supporting either a hosted runner or a self-hosted label set:

"ubuntu-latest"
["self-hosted", "linux", "x64", "visual-recap"]

Both gate and recap would use the configured runner. recap setup could write the variable through an opt-in flag, and recap doctor could validate it and report when no matching runner is available.

This feature would only select a runner. Users would register, operate, and secure their own GitHub runners.

Security boundary

Persistent self-hosted runners must not execute code from public forks or other untrusted authors. When self-hosted mode is configured, the gate should fail closed for those pull requests.

Documentation should recommend ephemeral runners or private repositories limited to trusted contributors. GitHub-hosted behavior remains unchanged.

Acceptance criteria

  • Existing installations use ubuntu-latest without configuration.
  • One canonical workflow supports hosted and self-hosted runner labels.
  • Both workflow jobs use the selected runner.
  • Setup and doctor support the self-hosted configuration.
  • Untrusted fork pull requests cannot reach the self-hosted recap job.
  • Tests cover the default, self-hosted selection, invalid configuration, and fork safety.
  • Documentation states that runner installation and maintenance remain the user's responsibility; Agent Native does not provide them.

Maintainer question

Would you be open to this approach? A repository or organization variable keeps one generated workflow and supports organization-wide configuration. Setup-time rendering is also possible if that boundary better fits the project.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    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