ci: add native ARM64 build and publishing

[michaelgold]

Summary

• add a dedicated GitHub-hosted pull-request validation workflow with no self-hosted jobs
• remove pull_request triggers from every workflow that can target persistent self-hosted runners
• register native DGX Spark ARM64/GPU CI as an explicitly labeled trusted-main target
• constrain all existing AMD64 workflows to Linux/X64 runners
• build, GPU-smoke, validate Remesher node registration, and publish ARM64 images on trusted main runs
• publish arm64, arm64-<commit>, and <ComfyUI-version>-arm64 tags without changing latest

Trust boundary

• PR-controlled workflow code runs only on ubuntu-24.04
• no workflow containing a self-hosted job has a pull_request trigger
• Spark runs only from refs/heads/main, including manual dispatch
• actions/checkout is pinned in the new workflows
• legacy AMD64 jobs require [self-hosted, Linux, X64]
• native ARM64 jobs require [self-hosted, Linux, ARM64, spark, gpu]

Native gates

• host and container architecture are aarch64
• NVIDIA GPU visible; CUDA available and capability >= 12.0
• PyTorch, Open3D, CUMM, and SPCONV import
• isolated bpy reports 5.2.1
• zero startup import failures
• all four pinned Remesher workflows resolve through /object_info
• Docker Hub publication occurs only after every gate passes

Publication and cleanup

• registry logout runs through an EXIT trap
• remote readback compares the pushed digest and asserts linux/arm64
• cleanup removes per-run/SHA/version tags
• the pre-pull arm64 image ID is removed only after displacement and only when it has no remaining tags
• the new arm64 cache tag and any independently tagged image are retained
• no broad Docker image prune is used

Local verification

• focused workflow/Dockerfile tests: 4 passed
• actionlint 1.7.7: pass
• AMD64 and ARM64 BuildKit --check: pass, zero warnings
• AMD64 and ARM64 Compose config: pass
• YAML parsing and git diff --check: pass
• disposable Docker cleanup lifecycle:
  • untagged displaced image removed
  • tagged displaced image retained
  • current arm64 cache retained

[Copilot]

🟡 Changes recommended

The newly added workflow tests rely on PyYAML’s on:→True parsing quirk, making them brittle across YAML parser behavior and potentially causing false positives/negatives.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR updates CI to enforce a clearer trust boundary: pull requests are validated only on GitHub-hosted runners, while self-hosted runners are reserved for trusted main runs, and adds a native ARM64 (Spark/GPU) build/test/publish pipeline.

Changes:

• Add a dedicated pull_request validation workflow that runs only on ubuntu-24.04 and checks Docker/workflow contracts.
• Remove pull_request triggers from self-hosted workflows and constrain existing self-hosted jobs to [self-hosted, Linux, X64].
• Add a main-only native ARM64 workflow that validates gates (GPU/CUDA/imports/Remesher checks) before publishing ARM64 image tags.

File summaries

File	Description
tests/test_arm64_workflow.py	New tests enforcing runner-label and trigger trust-boundary rules for workflows and ARM64 publication gates.
.github/workflows/validate-pull-request.yml	New GitHub-hosted PR validation workflow to avoid running PR code on self-hosted runners.
.github/workflows/health-check.yml	Constrains the self-hosted health-check job to explicit Linux/X64 runner labels.
.github/workflows/deploy.yml	Removes PR trigger and constrains self-hosted deploy jobs to Linux/X64 runner labels.
.github/workflows/deploy-nightly.yml	Constrains nightly self-hosted jobs to Linux/X64 runner labels.
.github/workflows/deploy-arm64.yml	New native ARM64 build/test/publish workflow gated to trusted main runs on labeled Spark/GPU ARM64 runners.
.github/actionlint.yaml	Adds actionlint config declaring additional self-hosted labels (spark, gpu).

Review details

Suppressed comments (2)

tests/test_arm64_workflow.py:31

• This test currently uses workflow.get(True, {}) / validation[True] / workflow[True] to read the on: section, which will fail (or silently skip) if the YAML loader returns an explicit "on" key instead of True. Use the helper _on_section() so the assertions remain stable across YAML parser behavior.

def test_pull_requests_never_run_on_self_hosted_runners():
    for path in [*WORKFLOWS.glob("*.yml"), *WORKFLOWS.glob("*.yaml")]:
        workflow = yaml.safe_load(path.read_text())
        if "pull_request" not in workflow.get(True, {}):
            continue

tests/test_arm64_workflow.py:59

• These assertions also read the on: section via workflow[True], which depends on PyYAML parsing on as a boolean. Prefer _on_section(workflow) and assert against that mapping instead.

    assert workflow["name"] == "Build and Publish Native ARM64 Image"
    assert "pull_request" not in workflow[True]
    assert "push" in workflow[True]
    assert workflow[True]["push"]["branches"] == ["main"]

• Files reviewed: 7/7 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🔵 Needs a closer look

It introduces and modifies high-impact CI/CD publishing workflows (including self-hosted ARM64 + Docker Hub publication), which warrants final human validation of the runner and registry behavior.

Review details

Suppressed comments (4)

Previously missed (2) — in code that hasn't changed since the last review.

.github/workflows/deploy.yml:88

• This self-hosted job still uses an unpinned actions/checkout@v4. On persistent self-hosted runners, pinning actions to a full commit SHA reduces supply-chain risk and aligns with the new pinned workflows in this PR.

This issue also appears on line 158 of the same file.

    runs-on: [self-hosted, Linux, X64]
    timeout-minutes: 300
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

.github/workflows/deploy-nightly.yml:25

• This self-hosted job still uses an unpinned actions/checkout@v4. On persistent self-hosted runners, pinning actions to a full commit SHA reduces supply-chain risk and matches the pinning approach used in the new workflows added by this PR.

This issue also appears on line 61 of the same file.

    runs-on: [self-hosted, Linux, X64]
    timeout-minutes: 120
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

.github/workflows/deploy.yml:169

• This self-hosted publish job uses docker/login-action@v3 as a floating tag. For the same trust-boundary reasons as actions/checkout, consider pinning this action to a commit SHA to reduce exposure to upstream action changes.

    runs-on: [self-hosted, Linux, X64]
    timeout-minutes: 60
    strategy:
      matrix:
        cuda:
          - tag_suffix: cuda12.8
            latest: false
          - tag_suffix: cuda13.0
            latest: true
    steps:
      - name: Log in to Docker Hub
        uses: docker/login-action@v3

.github/workflows/deploy-nightly.yml:61

• This self-hosted publish job uses docker/login-action@v3 as a floating tag. Pinning third-party actions to commit SHAs helps protect persistent self-hosted runners from supply-chain updates.

    runs-on: [self-hosted, Linux, X64]

• Files reviewed: 7/7 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟢 Approval recommended

The workflow triggers, runner constraints, and action pinning align with the stated trust boundary and are enforced by added contract tests.

Review details

• Files reviewed: 7/7 changed files
• Comments generated: 0 new
• Review effort level: Lite