Skip to content

Evaluate migrating CI from self-hosted runners to GitHub-hosted (Large) runners #3915

@jolestar

Description

@jolestar

Background

We currently use self-hosted runners for multiple workflows, including check_build_test.yml, docker_build.yml, and deploy_{mainnet,testnet}.yml. The self-hosted CI pool is costly; recent billing analysis suggests meaningful savings if we migrate heavy builds to GitHub-hosted Large runners.

Goals

  • Evaluate replacing the self-hosted runner for CI with GitHub-hosted Large runners (Linux).
  • Confirm only check_build_test.yml requires Large runner capacity; others can use standard hosted runners.
  • Assess impact and plan for deploy_* workflows (they currently SSH into GCP VMs and may need adjustments if moved off self-hosted).

Findings so far

  • check_build_test.yml is the heavy workflow (Rust build/tests + Move + web/SDK + Docker pulls) and is the primary candidate for GitHub-hosted Large runner.
  • docker_build.yml builds and pushes to GHCR; likely can run on standard hosted runners (no private network dependency), but includes a deploy-dev step that uses SSH to a GCP VM.
  • deploy_mainnet.yml and deploy_testnet.yml are SSH-based deployments; migration to hosted runners likely needs IP allowlist changes or alternative deployment path.

Suggested next steps

  1. Decide the target GitHub-hosted Large runner size (likely 16-core Linux to match n2d-standard-16).
  2. Modify check_build_test.yml to use the Large runner label/group.
  3. Migrate docker_build.yml build job to standard hosted runner; keep or refactor deploy-dev step.
  4. Decide how to handle deploy_* workflows if self-hosted runners are removed.

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions