Feat: TEM-14 functional testing - #28
Conversation
|
Had a proper look through this, including both linked runs and the generated-image artifact. The functional test itself looks good, the latest run checked out the exact PR head, passed on 15 GPU types with no functional failures, and uploaded 15 real 512×512 PNGs. The remaining skips were capacity/scheduler related. I don’t think the release wiring is quite ready yet though:
Could you sort those out before merge? One cross-PR note: #17 also rewrites Small non-blocking cleanup: a few comments/help strings still say the functional check runs over SSH or in-pod, while the implementation now runs host-side through the proxy. |
|
Thanks, the three points from my previous comment look sorted now: the release functional test is enabled, the ComfyUI workflows use the GPU profile, and the release job waits for the test. I spotted one more issue while checking the updated release job. Could you also run a fresh build/smoke test against the current head? The linked successful runs are still from |
Summary
Adds functional testing for the ComfyUI images on top of the existing smoke
tests: instead of only checking "does the container boot / is the port up?", we
now verify the image can actually generate an image end-to-end — the thing
that actually matters for a ComfyUI release.
The functional check mirrors a real user flow (pick the "1.1 Starter – Text to
Image" template → pull the missing model → run it → get a PNG), driven entirely
over the ComfyUI HTTP API.
What's new
Two ComfyUI test tiers (separate manifest flags, functional implies smoke):
The functional check runs entirely host-side against the public proxy URL
(
https://<pod-id>-8188.proxy.runpod.net) — no SSH, no in-pod script. Modelprovisioning uses the ComfyUI-RunpodDirect node baked into the image (its
/server_download/*routes live on the same ComfyUI server), exactly like the"Download to Pod" button in the UI. Flow:
/system_statsthrough the proxy,/server_download/verify_model_integrity→/server_download/start→ poll/server_download/status(server-sidesize + sha256 verification, 8-connection download on the pod),
POST /prompt, poll/history/<id>,GET /viewand assert a real, non-empty PNG (magic bytes + IHDR dimensions).Because it's bounded HTTP polling with per-request timeouts, there's no
hung-SSH risk of leaking a pod.
New files
tests/runpod_smoke/comfyui.py— the host-side functional check.tests/comfyui/workflows/gsl_starter_1_1.api.json— the "1.1 Starter – Textto Image" template in API format (fixed seed → reproducible).
tests/comfyui/models.json— checkpoint manifest (DreamShaper_8_pruned,with
sha256).tests/comfyui/images.example.yaml— example manifest for local runs.CI wiring
dev.yml— reachability smoke always on; functional is opt-in via arun_functional_testsworkflow_dispatchtoggle.release.yml— functional always on (a release gates on the imagebeing able to generate).
check-incompatibilities.yml— functional on every resolved GPU(
check_all_gpu) to surface GPU-specific generation failures.All three ComfyUI workflows use
profile: gpu: ComfyUI ships only GPUimages and
runpod/comfyui:latestcarries no CUDA marker, sobasewould sortit into
base_cpuand try to generate on a CPU pod.Generated images are archived as a workflow artifact
(
comfyui-generated-images,save-comfyui-images: true) — downloadable fromthe run Summary, never committed to the repo. Uploaded on
always(), soeven a failed generation surfaces whatever it produced.
New
smoke-testaction inputs:test-comfyui,test-comfyui-functional,save-comfyui-images,comfyui-images-artifact-name,comfyui-images-retention-days.Review follow-ups (addressed)
release.ymlsetstest-comfyui-functional: "true"directly (the oldrun_functional_testsinput didn't exist on that workflow, so it was silently off).
profile: gpuapplied acrossrelease.yml,dev.yml, andcheck-incompatibilities.yml(wasbase).release-comfyuinowneeds: [build-and-push, test],so the GitHub Release isn't published for an image that can't generate.
(Stable Docker tags are still pushed by
build-and-pushbeforehand; fullygating the image push needs the build/test/promote split, to be reconciled
with chore: automate releases with changesets #17's release.yml rewrite.)
public proxy, not over SSH / in-pod.
RELEASE_VERSION/IMAGE_REFcross-job fix — these were written to$GITHUB_ENVinbuild-and-pushand read from a separaterelease-comfyuijob, where they were empty (GitHub Release would get a blank tag/name). Now
IMAGE_REFis a single workflow-levelenv, and the dynamicrelease-versionis passed as abuild-and-pushjob output.pip==26.1.2andpip-tools==7.6.0— the base imageships an older
pip-tools, and a plainpip install pip-toolswon't upgradeit; combined with
get-pip.pypulling the newestpip, the stale(legacy-resolver)
pip-toolscrashed withmake_requirement_preparer() missing 'allow_editables'duringpip-compile. Pinning both makes lock-file generation reproducible.ci: refactor— removed deadIS_MANUAL_RELEASE/ redundantTAGwrites and fixed stale copied-from-
dev.ymlcomments inrelease.yml.Examples: