mirror of
https://github.com/comfyanonymous/ComfyUI.git
synced 2026-10-24 02:49:04 +03:00
bb352852ae
The stable-release bar names three packs by hand: "A staff member reproduces a break in KJNodes, VideoHelperSuite or ComfyUI-Manager" stops a release. Until now that reproduction was a person's job, and this repo has no custom-node tests at all -- the depth that exists is on the frontend side, which never sees a pack that fails to import in the first place. Installs the three at pinned commits, starts the server on CPU, and holds each pack against this build: - it imported (the server starts anyway when a pack fails, so the startup log is the only place that says so) - it registers the nodes it is known for - it did not quietly register fewer: a failed sub-import drops a block of nodes while the server still starts and nothing else complains - every node schema it registers is well formed, including that input_order only names inputs the node declares - the routes it adds answer, which for ComfyUI-Manager is the only evidence it loaded at all, since it registers no nodes The checks talk to a live server rather than importing nodes in-process because two of the three cannot be imported any other way: both ComfyUI-Manager and VideoHelperSuite touch PromptServer.instance at import time. Each check was verified against doctored input -- a pack import failure in the log, a sentinel node removed, a pack cut to 88 of its 244 nodes, an input_order naming an input that does not exist, a node whose input is not an object -- so they are known to fail when a pack actually breaks. KJNodes and VideoHelperSuite are pinned to the same commits as the frontend's custom-node suite, so a break reproduces in both against the same source. The node floors are floors rather than exact counts: a pack dropping a block of nodes is the regression worth failing on, and an exact count would also fail on a legitimate re-pin. The count measured at the pin is recorded next to each floor so a reviewer can see the size of the drop a failure reports. The job runs third-party setup and runtime code, so its checkout persists no credentials and its permissions are read-only.