Skip to content

PR-C: re-enable promoted GPU lane (deferred — no GPU strategy) #1225

@lmeyerov

Description

@lmeyerov

Status: DEFERRED — no GPU/self-hosted runner strategy is currently in flight. Tracking this issue separately from umbrella #1130 (now closed) so it isn't lost.

Background

Originally a child of #1130. PR-D (#1141, merged 2026-04-18) put ci-gpu.yml into a temporary lockdown — gpu_public execution gated behind vars.GRAPHISTRY_ENABLE_GPU_PUBLIC == 'true', currently false. PR-C is the work to re-enable that lane safely once a GPU strategy returns.

When to revisit

Any of:

  • The team decides to re-enable GPU CI (new dataset/test that requires it; renewed RAPIDS coverage commitment)
  • A self-hosted runner pool is provisioned (in-house or via a managed service)
  • A GitHub-hosted GPU runner SKU becomes generally available at acceptable cost

Acceptance criteria (from prior umbrella body)

  • Keep using existing ci-gpu.yml; do NOT add separate maintainer-ops / promoted workflow files unless a concrete need appears
  • Re-enable execution only with explicit maintainer promotion gate (label-gated, environment-approved, or trusted-ref-checked — pick one consistent with the rest of Umbrella: Harden untrusted PR CI + Codex agent security model #1130's hardening)
  • Verify and document runner ephemerality / reset guarantees before re-enabling any self-hosted execution
  • The provider safelist (PR-G 7a, zizmor unpinned-uses + repo Actions allowlist) and persist-credentials discipline (PR-B) must continue to apply on the GPU lane

Out of scope here

  • Anything not specifically about turning the GPU lane back on. New GPU-only feature work belongs in its own issue.

Related context (for the next maintainer to read)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions