mirror of
https://github.com/Comfy-Org/ComfyUI_frontend.git
synced 2026-07-09 00:29:22 +00:00
941f151520
## Summary Stop running the full Vitest suite twice in unit CI. The critical coverage gate is now a glob-keyed `coverage.thresholds` entry enforced during the single `pnpm test:coverage` run, instead of a second `COVERAGE_CRITICAL=true vitest run --coverage` pass. ## Changes - **What**: All critical directories form one brace-expanded glob key in `coverage.thresholds`; Vitest aggregates the matching files into a single bucket and checks the existing thresholds (69/60/67/70) against it during the normal coverage run. Untested files matching `coverage.include` are counted at 0%, preserving the previous gate's semantics. - **What**: Narrows the litegraph coverage exclusion from a blanket `src/lib/litegraph/**` to the non-critical subfolders, so the critical litegraph folders (`node`, `subgraph`, `utils`) are present in the coverage report the thresholds read. - **What**: Removes the `test:coverage:critical` script, the `COVERAGE_CRITICAL` env branch in `vite.config.mts`, and the separate CI gate step. ## Notes - The normal coverage report now includes the critical litegraph folders, so the Codecov `unit` flag and the coverage Slack baseline will show a one-time shift. - Filtered local runs (`pnpm test:coverage <file>`) fail the gate since most critical files are uncovered; a full `pnpm test:coverage` reproduces CI exactly. Validation: - `pnpm typecheck`, `pnpm exec eslint vite.config.mts`, `pnpm format:check`, `pnpm knip` (pre-push) - Smoke: `pnpm vitest run --coverage src/utils/colorUtil.test.ts` — tests pass, then the gate fails all four metrics against the critical bucket and exits 1, confirming enforcement happens inside the single run - Full-suite gate numbers should be confirmed in CI
GitHub Workflows
Naming Convention
Workflow files follow a consistent naming pattern: <prefix>-<descriptive-name>.yaml
Category Prefixes
| Prefix | Purpose | Example |
|---|---|---|
ci- |
Testing, linting, validation | ci-tests-e2e.yaml |
release- |
Version management, publishing | release-version-bump.yaml |
pr- |
PR automation (triggered by labels) | pr-claude-review.yaml |
api- |
External Api type generation | api-update-registry-api-types.yaml |
i18n- |
Internationalization updates | i18n-update-core.yaml |
Documentation
Each workflow file contains comments explaining its purpose, triggers, and behavior. For specific details about what each workflow does, refer to the comments at the top of each .yaml file.
For GitHub Actions documentation, see Events that trigger workflows.