Add publish frontend types workflow #5495
Conversation
🎭 Playwright Test Results✅ All tests passed! ⏰ Completed at: 09/15/2025, 08:25:56 PM UTC 📈 Summary
📊 Test Reports by Browser
🎉 Click on the links above to view detailed test results for each browser configuration. |
There was a problem hiding this comment.
Should we add this to the release process? And remove this:
ComfyUI_frontend/.github/workflows/release.yaml
Lines 127 to 159 in 3bc25b7
sure let me investigate deduping these two |
There was a problem hiding this comment.
Comprehensive PR Review
This review is generated by Claude. It may not always be accurate, as with human reviewers. If you believe that any of the comments are invalid or incorrect, please state why for each. For others, please implement the changes in one way or another.
Review Summary
PR: Add publish frontend types workflow (#5495)
Impact: 116 additions, 32 deletions across 2 files
Issue Distribution
- Critical: 0
- High: 0
- Medium: 3
- Low: 2
Category Breakdown
- Architecture: 1 issues
- Security: 2 issues
- Performance: 1 issues
- Code Quality: 2 issues
Key Findings
Architecture & Design
The PR successfully refactors the type publishing logic from release.yaml into a reusable workflow. This follows good CI/CD practices by creating modular, reusable workflows. The new workflow supports both manual triggering and workflow_call invocation, providing flexibility for different publishing scenarios.
Security Considerations
Two medium-priority security concerns were identified:
- Input validation missing: The 'ref' parameter lacks validation, potentially allowing malicious git references
- Version format validation: The version input should be validated against semantic versioning patterns to prevent injection attacks
Performance Impact
The workflow uses fetch-depth: 0 which may be unnecessary for a simple build-and-publish operation, potentially impacting checkout performance.
Integration Points
The refactoring properly maintains the existing release workflow functionality while adding the ability to manually publish types. The use of secrets: inherit ensures proper npm token access.
Positive Observations
- Clean separation of concerns by extracting type publishing into its own workflow
- Proper use of GitHub Actions best practices (concurrency control, conditional publishing)
- Includes version verification to prevent publishing mismatched versions
- Implements duplicate publication checks to avoid unnecessary publishes
- Good use of workflow_call for reusability
References
Next Steps
- Address medium-priority security issues (input validation)
- Consider standardizing action versions across workflows
- Evaluate if full git history is needed for the build process
- Test the manual workflow trigger functionality
This is a comprehensive automated review. For architectural decisions requiring human judgment, please request additional manual review.
| run: | | ||
| set -euo pipefail | ||
| VERSION="${{ inputs.version }}" | ||
| SEMVER_REGEX='^(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)(-((0|[1-9][0-9]*|[0-9]*[A-Za-z-][0-9A-Za-z-]*)(\.(0|[1-9][0-9]*|[0-9]*[A-Za-z-][0-9A-Za-z-]*))*))?(\+([0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*))?$' |
There was a problem hiding this comment.
https://regex101.com/r/8W7AN9/1
test cases and inspiration from https://semver.org/#is-there-a-suggested-regular-expression-regex-to-check-a-semver-string
| steps: | ||
| - name: Checkout code | ||
| uses: actions/checkout@v4 | ||
| uses: actions/checkout@v5 |
There was a problem hiding this comment.
just upgrading to node 24
Summary
Adds a manually triggered github workflow to publish frontend types versions to npm.
Takes a
versionanddist_tag.Checksout to
version, builds types, verifies givenversionmatches built version, publishes to npm givendist_tag.┆Issue is synchronized with this Notion page by Unito