feat: add component contributor test harness

[ArangoGutierrez]

Summary

Validate AICR components end-to-end with a single command — no GPU hardware required for most components.

make component-test COMPONENT=cert-manager

• Three test tiers (auto-detected from registry.yaml): scheduling (KWOK redirect), deploy (Kind + bundle + health check), gpu-aware (Kind + nvml-mock + deploy + health check)
• nvml-mock integration using ghcr.io/nvidia/nvml-mock:0.1.0 for GPU simulation in Kind clusters (arm64 + amd64, includes nvidia-smi)
• Bundler bugfix: deploy.sh template now conditionally includes --version flag — fixes broken helm commands for components without defaultVersion in registry (e.g., gpu-operator)

New files

• tools/component-test/ — 7 scripts (detect-tier, ensure-cluster, setup-gpu-mock, deploy-component, run-health-check, cleanup), Kind config, nvml-mock manifest, README
• Makefile targets: component-test, component-detect, component-cluster, component-deploy, component-health, component-cleanup
• Documentation updates in DEVELOPMENT.md and CONTRIBUTING.md

Test Plan

• make test — all unit tests pass (72.1% coverage)
• make component-test COMPONENT=cert-manager — deploy tier end-to-end (build → deploy → health check → cleanup)
• make component-test COMPONENT=gpu-operator TIER=gpu-aware — gpu-aware tier end-to-end (build → nvml-mock → deploy → health check → cleanup)
• make component-test COMPONENT=cert-manager TIER=scheduling — scheduling tier redirects to KWOK
• New tests: TestGenerateDeployScript_EmptyVersionOmitsFlag, TestGenerateDeployScript_WithVersionIncludesFlag

[kannon92]

So rather than go with mock GPUs is there a way we could have a CPU flavor?

I like that pattern for llama.cpp or vllm.

[ArangoGutierrez]

So rather than go with mock GPUs is there a way we could have a CPU flavor?

I like that pattern for llama.cpp or vllm.

Good question — the harness actually already has a GPU-free path. The deploy tier validates components in plain Kind without any GPU mock (cert-manager, kai-scheduler, etc. use this today).

The nvml-mock layer is specifically for components that gate on GPU presence during init — gpu-operator, nvidia-device-plugin, DRA driver — they won't even start their reconciliation loop unless they
detect NVML libraries and device nodes on the host. There's no CPU flavor of those because their entire purpose is managing GPU hardware.

For inference workloads like llama.cpp or vLLM, a CPU flavor would make sense as a complementary pattern — deploy the serving stack with a CPU backend and validate the end-to-end request path. That's a
higher-level integration test than what this harness targets (component deployment + health check), but it could be built on top of it.

So both patterns have a place:

• nvml-mock: GPU infrastructure components that check for hardware at init
• CPU flavors: inference/serving workloads that can run with CPU backends

[kannon92]

Thanks for this! This should help me a lot of Kueue work.

[ArangoGutierrez]

CI is passing, ready for review @yuanchen8911 / @mchmarny