This pull request updates the workflow for managing Playwright
expectation snapshots in
`.github/workflows/pr-update-playwright-expectations.yaml`. The main
focus is to improve how changed snapshot files are handled, ensuring
directory structures are correct and only necessary files are processed
and committed. The most important changes are grouped below:
**Snapshot file handling improvements:**
* When copying changed snapshot files, the workflow now strips the
`browser_tests/` prefix to avoid double nesting in the staging
directory. This ensures the directory structure remains correct when
files are merged back.
* During the merging step, the script clarifies that files are already
in the correct structure (without the `browser_tests/` prefix), so they
can be copied directly into `browser_tests/`.
**Workflow and commit logic enhancements:**
* The snapshot artifact download step is renamed for clarity, indicating
that only changed snapshot files are downloaded from shards.
* The commit step is improved to check for actual changes in
`browser_tests/` before attempting to commit and push. It sets an output
variable (`has-changes`) to control subsequent steps, adds more
informative logging, and only pushes when there are changes.
* The "Add Done Reaction" step is now conditional on both the event type
and whether there were changes to commit, preventing unnecessary
reactions.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6252-Hotfix-CI-update-test-expectations-2966d73d36508131968ee5a7f04ff787)
by [Unito](https://www.unito.io)
---------
Co-authored-by: github-actions <github-actions@github.com>
This pull request updates the Playwright snapshot update workflow to
improve efficiency and clarity. The workflow now only uploads and merges
changed snapshot files from each shard, reducing unnecessary artifact
size and processing. It also adds better logging and summaries for
easier debugging and review.
**Snapshot handling improvements:**
* Only changed snapshot files are identified, staged, and uploaded as
artifacts per shard, instead of uploading all snapshot files. This
reduces artifact size and upload time.
* During the merge step, only the changed files from each shard are
merged back into the `browser_tests` directory, preserving directory
structure and avoiding redundant operations.
**Logging and debugging enhancements:**
* Added steps to list downloaded snapshot files and summarize the
changes after merging, making it easier to see what was updated and
debug any issues.
Sample run is here
https://github.com/Myestery/ComfyUI_frontend/actions/runs/18768857441
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6250-Patch-Update-expectations-CI-2966d73d365081b790a0fad66649a10b)
by [Unito](https://www.unito.io)
This pull request makes a small change to the
`.github/workflows/pr-update-playwright-expectations.yaml` file,
removing the unconditional `if: always()` condition from the
`merge-and-commit` job. This means the job will now only run if its
dependencies succeed, rather than always running regardless of previous
job outcomes.
This pull request significantly refactors the Playwright expectations
update workflow to improve reliability, efficiency, and maintainability.
The workflow is now split into three coordinated jobs—setup, sharded
snapshot updates, and merge/commit—enabling parallel test execution and
artifact management. Key improvements include sharding Playwright
snapshot updates, robust caching and artifact handling, and more
reliable PR context handling.
**Workflow Restructuring and Sharding:**
* The workflow is split into three jobs: `setup` (prepares environment
and caches it), `update-snapshots-sharded` (runs Playwright snapshot
updates in four parallel shards), and `merge-and-commit` (merges results
and commits updates). This enables faster, more reliable snapshot
updates.
[[1]](diffhunk://#diff-0289f4b5962314fa2d58937651c3d2a0f2c6f76e26c95d6a04d43c18b3449917L15-R15)
[[2]](diffhunk://#diff-0289f4b5962314fa2d58937651c3d2a0f2c6f76e26c95d6a04d43c18b3449917R27-R175)
**Caching and Artifact Management:**
* The setup job builds and caches the entire workspace, which is then
restored by each shard for consistent environments. Each shard uploads
its updated snapshots and test reports as artifacts, which are later
downloaded and merged in the final job.
**Improved PR Context Handling:**
* PR number, branch, and comment IDs are now reliably extracted and
passed between jobs using outputs, ensuring correct association with the
PR throughout the workflow (e.g., for commenting, reactions, and pushing
updates).
[[1]](diffhunk://#diff-0289f4b5962314fa2d58937651c3d2a0f2c6f76e26c95d6a04d43c18b3449917R27-R175)
[[2]](diffhunk://#diff-0289f4b5962314fa2d58937651c3d2a0f2c6f76e26c95d6a04d43c18b3449917L92-R199)
**Job and Step Renaming/Cleanup:**
* The main job is renamed from `test` to `setup`, and redundant or
unnecessary steps (such as the old branch SHA extraction) are removed
for clarity and maintainability.
[[1]](diffhunk://#diff-0289f4b5962314fa2d58937651c3d2a0f2c6f76e26c95d6a04d43c18b3449917L15-R15)
[[2]](diffhunk://#diff-0289f4b5962314fa2d58937651c3d2a0f2c6f76e26c95d6a04d43c18b3449917R27-R175)
**Comment and Label Automation Improvements:**
* Automated GitHub comment reactions and label removals now use the
correct PR context, ensuring that feedback and status updates are
reliably posted to the right place.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6100-Shard-Update-Test-Expectations-PR-28f6d73d36508109bcd8d382c942d44d)
by [Unito](https://www.unito.io)
---------
Co-authored-by: sno <snomiao@gmail.com>
## Summary
Removes duplicate tarball creation from desktop-ui publish workflow -
`pnpm publish` handles this internally.
## Changes
- **What**: Removes `npm pack` step and GitHub Actions artifact upload
- **Breaking**: None - workflow behavior unchanged, publish still works
identically
## Review Focus
The `npm pack` + artifact upload was creating a duplicate of what `pnpm
publish` generates and uploads to npm anyway. Verified
`publish-frontend-types.yaml` follows this same pattern (no pack step,
direct publish).
Add support for downloading and displaying Playwright E2E test reports
in the GitHub Pages deployment workflow. The reports are organized by
browser (chromium, chromium-2x, chromium-0.5x, mobile-chrome) and
presented via an interactive index page with test statistics.
Changes:
- Download Playwright reports from CI test runs (both triggered and latest)
- Organize reports into browser-specific directories
- Create interactive index page showing test stats (passed/failed/skipped/flaky)
- Integrate with existing .pages landing page
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
## Summary
Added configurable base branch selection to version bump workflows,
enabling patch releases from `core/*` branches via GitHub Actions UI.
## Changes
- **What**: Extended [workflow_dispatch
inputs](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch)
with `branch` parameter for both main frontend and desktop-ui version
bump workflows
- **Validation**: Added branch existence check that lists available
`core/*` branches on error
- **Workflow modifications**:
- `release-version-bump.yaml`: Checkout and create PRs targeting
user-specified branch
- `version-bump-desktop-ui.yaml`: Same behavior for desktop-ui releases
## Review Focus
Branch validation logic correctly handles both local (`refs/heads/`) and
remote (`refs/remotes/origin/`) refs. Default value preserves backward
compatibility for release sheriffs unfamiliar with new feature.
## Use Case
Previously, patch releases from `core/1.29` required manual version
bumping. Now maintainers can trigger from Actions UI with dropdown
selections.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6117-ci-allow-manual-workflow-dispatch-to-do-version-bumping-on-core-branches-rather-than-j-2906d73d365081cba3aff46471206a9e)
by [Unito](https://www.unito.io)
## Summary
Expands the PR backport workflow so maintainers can target any release
branch using labels, instead of being limited to the `core/x.y` release
lines. The workflow now collects labels formatted as plain version
numbers (`1.24`) as before, plus new prefixes like
`branch:release/hotfix` or `backport:partner/foo`, validates that each
referenced branch exists, and then cherry-picks the source merge commit
to every target.
All generated PRs and failure comments reference the actual branch name,
making it clear where the backport landed or why it failed. This keeps
the existing opt-in flow (`needs-backport`) but makes it flexible enough
for custom support and partner branches without extra manual work.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6108-ci-extend-backport-workflow-to-work-with-arbitrary-branches-28f6d73d365081bf85a3d4c40a23bb68)
by [Unito](https://www.unito.io)
Add debug step to list contents of .pages directory before Vercel deployment
to help troubleshoot deployment issues.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Add github.run_id to cache key to prevent cache hits and ensure
every run saves a new cache entry.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Enable GitHub comments for deployment notifications
- Update alias domain to use 'reports' instead of 'docs'
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Create dedicated pages-dev-server job that runs bun pages:dev
- Runs in parallel with incremental-build as a background task
- Uses bun for faster package management and dev server execution
- Includes proper dependency installation and Node.js setup
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Install bun runtime for faster package management
- Start pages:dev server in background during build process
- Track dev server PID for proper cleanup
- Ensure dev server is stopped after build completion
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Add build artifact caching using branch name as cache key
- Cache .pages, storybook-static, and coverage directories
- Configure Vercel deployment with branch-specific alias domains
- Optimize build performance with cache restore fallbacks
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Replace actions/download-artifact@v4 with dawidd6/action-download-artifact@v6
- Use single action for both same-run and cross-workflow downloads
- Simplifies maintenance and reduces action dependencies
- Maintains all existing fallback logic
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Update actions/download-artifact@v3 to v4
- Update actions/upload-pages-artifact@v3 to v4
- Update dawidd6/action-download-artifact@v3 to v6
Resolves CI/CD failure with deprecated artifact actions.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Update vitest-reports artifact download paths to use .gh-pages-cache for better organization
- Fix .gitignore core dump pattern to be more general (core instead of /core)
- Update .pages structure with migrated documentation and configuration
- Refine Knip configuration to exclude .pages directory while keeping vite.config.ts
- Improve build-pages.sh script to use relative paths consistently for .pages directory
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
chore(knip.config.ts): add public directory and vite.config.ts to Knip config for better type management
feat(package.json): add build:pages script to automate page building process
Deploy multiple development tools to GitHub Pages on every merge to main branch:
- Storybook (primary priority for design team collaboration)
- Nx dependency graph
- Test coverage reports (Vitest)
- TypeDoc API documentation
- Knip unused code analysis
The deployment provides a consistent bookmarkable URL for the design team
to reference the latest component system state, eliminating the need for
PR-specific Storybook links.
All tools except Storybook are optional (continue-on-error) to ensure
deployment succeeds even if individual tools fail to build.
Includes comprehensive documentation in docs/GITHUB_PAGES_DEPLOYMENT.md
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
## Problem
The `update-playwright-expectations.yaml` workflow was failing with:
```
error: argument --front-end-root: The path '../dist' does not exist.
```
This was happening because the workflow was trying to launch the ComfyUI
server with `--front-end-root ../dist` before building the frontend.
## Root Cause
The workflow was missing the frontend build step entirely. It went
directly from checkout → setup server with `launch_server: true` → run
tests, skipping the crucial frontend build.
## Solution
1. Remove `launch_server: true` from `setup-comfyui-server` action call
2. Add `setup-frontend` action with `include_build_step: true` to build
the frontend
3. Add separate "Launch ComfyUI Server" step that runs AFTER frontend is
built
This ensures the `dist/` directory exists before the server tries to use
it.
## Testing
This fixes errors seen on PR #5863 and any PR using the
`/update-playwright` comment trigger.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6005-bugfix-Fix-update-playwright-expectations-workflow-missing-frontend-build-2876d73d36508182bb1af1123f3b2a87)
by [Unito](https://www.unito.io)
## Summary
This PR refactors the GitHub Actions workflow structure to improve
reusability, maintainability, and CI performance.
## Changes
### New Actions
- **setup-comfyui-server**: New composite action that handles ComfyUI
server setup and launch
- Checks out ComfyUI repository
- Installs ComfyUI_devtools custom node
- Sets up Python environment and dependencies
- Optionally launches the server with configurable parameters
### Refactored Actions
- **setup-frontend**: Simplified to focus only on frontend-specific
tasks
- Installs pnpm and Node.js
- Installs dependencies
- Optionally builds the frontend (can be skipped when using cached
builds)
- No longer handles server setup or checkout
### Workflow Improvements
#### tests-ci.yaml
- Introduced a setup job that builds once and caches the entire
workspace
- Test jobs now restore the cached workspace instead of rebuilding
- Eliminated redundant setup steps in each test shard
- Better separation between setup and test execution phases
- Significant performance improvement through workspace caching
#### Locale Update Workflows
- Updated `update-locales.yaml` to use the new action structure
- Updated `update-locales-for-given-custom-node-repository.yaml` with
proper custom node installation
- Updated `update-node-definitions-locales.yaml` to use new actions
- Removed `working-directory` references where appropriate
#### Other Workflows
- Updated `update-playwright-expectations.yaml` to use new action
structure
- Consistent action usage across all workflows
## Benefits
1. **Better Performance**: Workspace caching eliminates redundant builds
in CI, significantly reducing test execution time
2. **Improved Maintainability**: Clear separation of concerns makes
actions easier to understand and modify
3. **Enhanced Reusability**: Actions can be composed in different ways
for different workflows
4. **DRY Principle**: Eliminated code duplication across workflows
5. **Easier Debugging**: Smaller, focused actions make it easier to
identify and fix issues
## Testing
- [ ] Verify tests-ci workflow runs successfully
- [ ] Verify locale update workflows function correctly
- [ ] Verify playwright expectations update workflow works
- [ ] Confirm cache/restore mechanism works as expected
## Related Issues
This refactoring addresses workflow complexity and reduces CI runtime by
leveraging GitHub Actions caching more effectively.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5949-refactor-Reorganize-GitHub-Actions-for-better-reusability-2846d73d365081ae8e16f151423b5a88)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Alexander Brown <drjkl@comfy.org>
Co-authored-by: DrJKL <DrJKL0424@gmail.com>
## Summary
Automatically removes the `New Browser Test Expectations` label after
the Playwright expectations update workflow completes.
## Changes
- Added a cleanup step to
`.github/workflows/update-playwright-expectations.yaml` that removes the
label using `gh pr edit --remove-label`
- Uses `if: always() && github.event_name == 'pull_request'` to ensure:
- The label is removed even if the workflow fails
- The label is only removed when triggered by the label event (not the
`/update-playwright` comment trigger)
## Benefits
- Cleaner PR label management
- Labels can be re-applied to trigger additional expectations updates
without manual cleanup
- Consistent with the claude-review workflow pattern
- Reduces noise in the PR interface
## Context
This is part of a broader effort to automatically clean up temporary
action-triggering labels across all workflows. The first PR in this
series (#5983) added the same functionality to the claude-review
workflow.
## Test Plan
- Apply the `New Browser Test Expectations` label to a PR to verify the
workflow removes it automatically after completion
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5998-feat-Auto-remove-New-Browser-Test-Expectations-label-after-workflow-completes-2876d73d365081e29fbbe6e3127ca973)
by [Unito](https://www.unito.io)
## Summary
Fixes the Playwright update workflow broken by #5960. When triggered by
adding the "New Browser Test Expectations" label, the workflow was left
in a detached HEAD state, causing `git push` to fail.
## Changes
- **Restores branch checkout for label triggers**: Uses
`github.head_ref` to fetch and checkout the branch when triggered by
`pull_request` events
- **Preserves comment trigger functionality**: Keeps `gh pr checkout`
for `issue_comment` events using `github.event.issue.number`
- **Event-specific push logic**: Uses explicit `git push origin HEAD:${{
github.head_ref }}` for label triggers, plain `git push` for comment
triggers
## Root Cause
PR #5960 removed the original branch checkout logic:
```yaml
git fetch origin ${{ github.head_ref }}
git checkout -B ${{ github.head_ref }} origin/${{ github.head_ref }}
git push origin HEAD:${{ github.head_ref }}
```
This left the label-triggered workflow in detached HEAD after
`actions/checkout@v5`, breaking the push step.
## Testing
This fix properly uses `github.head_ref` only when it's available
(`pull_request` events) and `github.event.issue.number` only for
`issue_comment` events where `head_ref` isn't available.
Fixes#5960
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5985-ci-Fix-detached-HEAD-state-in-Playwright-update-workflow-2866d73d36508183b63bca03a40da4a8)
by [Unito](https://www.unito.io)
## Summary
Automatically removes the `claude-review` label after the Claude PR
review workflow completes, regardless of success or failure.
## Changes
- Added a cleanup step to `.github/workflows/claude-pr-review.yml` that
removes the label using `gh pr edit --remove-label`
- Uses `if: always()` to ensure the label is removed even if the review
fails
- This prevents label accumulation and allows the label to be re-applied
for additional reviews
## Benefits
- Cleaner PR label management
- Labels can be re-applied to trigger additional reviews without manual
cleanup
- Reduces noise in the PR interface
## Test Plan
- Apply the `claude-review` label to this PR to verify the workflow
removes it automatically after completion
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5983-feat-Auto-remove-claude-review-label-after-CI-review-completes-2866d73d365081da929cd393996010e1)
by [Unito](https://www.unito.io)
## Problem
Our CI tests were experiencing non-reproducible results where:
- Tests would pass on a PR initially
- The same PR would fail later when main HEAD changed
- Screenshot comparisons showed excessive differences between expected
vs actual
- Blake identified: *"tests are not reproducible inside a branch - they
change every time main HEAD changes"*
## Root Cause
The issue was caused by **explicit `repository` parameters** in our
`actions/checkout` steps:
```yaml
- name: Checkout ComfyUI_frontend
uses: actions/checkout@v5
with:
repository: 'Comfy-Org/ComfyUI_frontend' # ← This was the problem!
path: 'ComfyUI_frontend'
```
According to GitHub Actions documentation:
> **When checking out the repository that triggered a workflow, `ref`
defaults to the reference or SHA for that event. Otherwise, uses the
default branch.**
When you specify an explicit `repository` parameter (even if it's the
same repo), GitHub Actions treats it as "otherwise" and defaults to the
**main branch** instead of using the **PR context**.
## The Fix
Remove the explicit `repository` parameter when checking out the same
repository:
```yaml
- name: Checkout ComfyUI_frontend
uses: actions/checkout@v5
with:
path: 'ComfyUI_frontend' # No repository parameter = uses PR context
```
## Changes Made
- ✅ Removed `repository: 'Comfy-Org/ComfyUI_frontend'` from setup job
checkout
- ✅ Removed `repository: 'Comfy-Org/ComfyUI_frontend'` from
merge-reports job checkout
- ✅ Updated setup-frontend action to use `actions/checkout@v5` for
consistency
- ✅ Simplified workflow by removing unnecessary `ref` and `fetch-depth`
parameters
## How This Fixes the Problem
**Before:**
- Setup job checked out main branch (due to explicit repository)
- Tests ran PR code against main branch snapshots
- Results varied based on what was in main at the time
**After:**
- Setup job checks out PR merge commit (natural PR context)
- Tests run PR code against PR snapshots
- Results are consistent and reproducible
## Why It Worked Before (Sometimes)
The explicit `repository` parameter has been there for a long time, but
the issue became more apparent recently due to:
1. GitHub Actions behavior changes over time
2. Increased frequency of main branch updates
3. More sensitive screenshot comparison tests
4. Complex cache/restore workflow where timing mattered
The fix ensures deterministic behavior regardless of GitHub's internal
changes.
## Testing
This change makes the CI behavior explicit and predictable:
- ✅ PR tests will always use PR context
- ✅ Push tests will always use pushed commit
- ✅ No dependency on GitHub's default behavior interpretation
- ✅ Simplified workflow with fewer moving parts
Resolves the issues described in `.github/workflows/problem.log`.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5950-Fix-CI-Remove-explicit-repository-parameter-causing-non-reproducible-test-results-2846d73d36508159a848c4a2e14a0fb1)
by [Unito](https://www.unito.io)
Co-authored-by: Alexander Brown <drjkl@comfy.org>
## Problem
The `update-locales` workflow was failing with the error:
```
Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under '/home/runner/work/ComfyUI_frontend/ComfyUI_frontend/.github/actions/setup-frontend'.
Did you forget to run actions/checkout before running your local action?
```
Ref:
https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18270266173/job/52011427608
## Solution
Added a checkout step using `actions/checkout@v5` before the "Setup
Frontend" step. This ensures the repository code (including the local
action definition) is available before GitHub Actions tries to use it.
## Changes
- Added checkout step to `.github/workflows/update-locales.yaml`
- Uses `actions/checkout@v5` to checkout the repository before
referencing the local custom action
This is a minimal fix that follows GitHub Actions best practices.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5938-fix-Add-checkout-step-before-using-local-action-in-update-locales-workflow-2846d73d365081cfb720ffaa528ce26e)
by [Unito](https://www.unito.io)
---------
Co-authored-by: github-actions <github-actions@github.com>
