## Summary
When multiple labels are added to a PR in quick succession (e.g.,
`needs-backport` and `core/1.33`), each label triggers a separate
workflow run. Both runs would proceed independently, causing duplicate
failure comments or redundant work. This adds a concurrency group keyed
by PR number with `cancel-in-progress: false`, ensuring runs for the
same PR are serialized rather than racing.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7335-fix-prevent-duplicate-backport-workflow-runs-for-same-PR-2c66d73d36508140a603cd7110c42442)
by [Unito](https://www.unito.io)
## Summary
Fixes an issue where Playwright HTML reports were not being generated
for `chromium-2x`, `chromium-0.5x`, and `mobile-chrome` test runs,
causing 404 errors when accessing report links in PR comments.
## Problem
Only the first report link (chromium) had contents - the other three
browsers returned 404 errors. Investigation revealed that artifacts for
non-chromium browsers were only uploading 1 file (report.json) instead
of the full HTML report with ~32 files.
The root cause was that these browsers run very few tests (1-6 tests
each), and when using `--reporter=html --reporter=json` together,
Playwright would only generate the JSON report without the HTML assets.
## Solution
Changed the workflow for non-chromium browsers to use the same approach
as the sharded chromium tests:
1. Run tests with `--reporter=blob`
2. Generate HTML and JSON reports separately using `merge-reports`
This ensures both HTML and JSON reports are always generated with
complete assets, regardless of test count.
## Testing
The fix can be verified by:
1. Checking that this PR's workflow run uploads similar file counts for
all browsers
2. Confirming all 4 report links are accessible and show proper HTML
content
Related to #7186🤖 Generated with [Claude Code](https://claude.com/claude-code)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7193-bugfix-Fix-E2E-test-report-generation-for-non-chromium-browsers-2c06d73d365081ba8ea3ed0d3f5d8d38)
by [Unito](https://www.unito.io)
Co-authored-by: Claude <noreply@anthropic.com>
Follow-up adjustments to the weekly ComfyUI release automation workflow.
## Changes
1. **Rename workflow to follow conventions**
- File: `weekly-comfyui-release.yaml` → `release-weekly-comfyui.yaml`
- Name: "Weekly ComfyUI Release" → "Release: Weekly ComfyUI"
- Matches pattern of other `release-*` workflows
2. **Sync fork with upstream before creating PR**
- Fetches latest upstream/master before making changes
- Ensures PR only shows requirements.txt diff, not stale fork commits
- Does not modify fork's master branch (only pushes automation branch)
## Testing
After merge, can test via manual workflow dispatch in Actions tab.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-7060-fix-Weekly-release-workflow-adjustments-2bb6d73d365081008436d1b9e5f7dd65)
by [Unito](https://www.unito.io)
Adds scheduled workflow to bump ComfyUI frontend RC releases every
Monday at noon PST.
## Implementation
- **Resolver script** (`scripts/cicd/resolve-comfyui-release.ts`):
Checks ComfyUI `requirements.txt` and determines next minor version,
compares branch commits to latest patch tag
- **Workflow** (`.github/workflows/weekly-comfyui-release.yaml`):
- Scheduled for Monday 20:00 UTC (noon PST)
- Manual dispatch supported for testing/off-cycle runs
- Three jobs: resolve version → trigger release if needed → create
ComfyUI PR
- Reuses existing `release-version-bump.yaml` workflow
- Creates draft PR from fork to `comfyanonymous/ComfyUI` with updated
`requirements.txt`
- Includes error handling and validation for all steps
- Force pushes to same branch weekly to maintain single open PR
## Testing
- Resolver script tested locally: correctly identified v1.28.8 → v1.29.4
with release needed
- yamllint passes
- knip passes with `gh` binary added to ignore list
## Follow-up
Can test via workflow_dispatch once merged, or in this PR if we enable
Actions on branch.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6877-feat-Add-weekly-ComfyUI-release-automation-2b46d73d36508154aa05c783c6942d9a)
by [Unito](https://www.unito.io)
## Summary
- add workflow to tag merged backport-labeled PRs into cloud/* with
cloud/v<package.json version>
- validate branch/version alignment and skip when tag already exists
- use .nvmrc (Node 24) for setup-node
## Question
- This workflow expects the version bump to already be in the PR when
you merge, as it fails if the tag already exists to keep immutability.
Should we autobump in this case?
## Summary
- Adds [Oxc linter](https://oxc.rs/docs/guide/usage/linter) as a dev
dependency
- Creates minimal `.oxlintrc.json` configuration file
- Integrates oxlint into the lint workflow (runs before ESLint)
- Adds `pnpm oxlint` script for standalone usage
- **NEW**: Adds
[eslint-plugin-oxlint](https://github.com/oxc-project/eslint-plugin-oxlint)
to disable redundant ESLint rules
- Updates `CLAUDE.md` documentation with oxlint command
## Motivation
Oxc is a high-performance Rust-based linter that is 50-100x faster than
ESLint. By integrating it into our lint workflow, we get:
- **Faster CI/CD pipelines** (5% improvement in this codebase)
- **Quicker local development feedback**
- **Additional code quality checks** that complement ESLint
- **Reduced duplicate work** by disabling ESLint rules that oxlint
already checks
## Changes
- **package.json**: Added `oxlint` and `eslint-plugin-oxlint` to
devDependencies, integrated into `lint`, `lint:fix`, and `lint:no-cache`
scripts
- **pnpm-workspace.yaml**: Added `eslint-plugin-oxlint` and
`mixpanel-browser` to catalog
- **eslint.config.ts**: Integrated `eslint-plugin-oxlint` to
automatically disable redundant ESLint rules
- **.oxlintrc.json**: Created minimal configuration file with schema
reference
- **CLAUDE.md**: Added `pnpm oxlint` to Quick Commands section
- **.gitignore**: Added `core` dump files
## CI/CD Performance Benchmark
Real-world CI/CD timing from GitHub Actions workflow runs:
### Baseline (ESLint only) - [Run
#18718911051](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18718911051)
- Run ESLint with auto-fix: **125s**
- Final validation (lint + format + knip): **16s**
- **Total: 141s**
### With Oxlint (oxlint + ESLint) - [Run
#18719037963](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18719037963)
- Run ESLint with auto-fix (includes oxlint): **118s**
- Final validation (includes oxlint + lint + format + knip): **16s**
- **Total: 134s**
### Results
✅ **7 seconds faster (5.0% improvement)** despite running an additional
linting pass
### Analysis
The oxlint integration actually **improves** CI/CD performance by ~5%.
This unexpected improvement is likely because:
1. **Oxlint catches issues early**: Some code that would have slowed
down ESLint's parsing/analysis is caught by oxlint first
2. **ESLint cache benefits**: The workflow uses `--cache`, and oxlint's
fast execution helps populate/validate the cache more efficiently
3. **Parallel processing**: Modern CI runners can overlap some of the
I/O operations between oxlint and ESLint
Even if oxlint added overhead, the value proposition would still be
strong given its additional code quality checks and local development
speed benefits. The fact that it actually speeds up the pipeline is a
bonus.
## eslint-plugin-oxlint Performance Impact
Benchmark comparing ESLint performance with and without
eslint-plugin-oxlint:
### Baseline (ESLint without plugin) - [Run
#18723242157](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18723242157)
- Run ESLint with auto-fix: **122s** (2m 2s)
- Final validation: **17s**
### With eslint-plugin-oxlint - [Run
#18723675903](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18723675903)
- Run ESLint with auto-fix: **129s** (2m 9s)
- Final validation: **12s**
### Results
**Performance: +7 seconds ESLint, -5 seconds validation (net +2
seconds)**
The eslint-plugin-oxlint integration has a **minimal performance
impact** (+2 seconds total). The slight increase in ESLint time is
likely due to the additional plugin configuration overhead, while the
validation step is faster because fewer redundant lint warnings need to
be processed.
### Benefits
The small performance cost is outweighed by important benefits:
1. **Prevents duplicate work**: Disables ~50 ESLint rules that oxlint
already checks (e.g., `no-constant-condition`, `no-debugger`,
`no-empty`, etc.)
2. **Reduces noise**: Eliminates redundant lint warnings from two tools
checking the same thing
3. **Cleaner workflow**: One authoritative source for each type of lint
check
4. **Best practice**: Recommended by the Oxc project for ESLint + oxlint
integration
5. **Consistent results**: Ensures both tools don't conflict or give
contradictory advice
## Usage
```bash
# Run oxlint standalone
pnpm oxlint
# Run full lint workflow (oxlint + ESLint)
pnpm lint
pnpm lint:fix
```
## Notes
- Oxlint now runs as part of the standard `pnpm lint` workflow
- The configuration uses minimal rules by default (Oxc's philosophy is
"catch erroneous or useless code without requiring any configurations by
default")
- Oxlint provides fast feedback while ESLint provides comprehensive
checks
- eslint-plugin-oxlint automatically manages rule conflicts between the
two tools
- Both tools complement each other in the linting pipeline
🤖 Generated with [Claude Code](https://claude.com/claude-code)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6197-chore-Add-Oxc-linter-to-project-2946d73d3650818cbb55ef9c0abdb9b9)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: DrJKL <DrJKL0424@gmail.com>
Fixes issue in which a failed backport runs would not cleanup the branch
(issue 1) and then on the next backport attempt, it would bail out early
because it checks if a branch with that name already exists (issue 2).
The workflow now treats existing backport branches as reusable unless an
open PR already references them (issue 2 solution), force-updates any
reused branch with the latest cherry-pick, and records them so a new
cleanup step can delete the branch if the run fails (issue 1 solution).
That prevents stranded refs from blocking future backport runs while
keeping active backport PRs intact.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6620-ci-fix-backport-workflow-not-cleaning-up-branch-on-failure-and-not-able-to-update-existi-2a36d73d365081efbbcbfa75f0c1bbe7)
by [Unito](https://www.unito.io)
- Remove Additions section from changelog output (no longer needed)
- Add line number tracking in API snapshots
- Generate GitHub permalinks to referenced code in changelog
- Update workflows to pass git reference for link generation
- Breaking changes and modifications now link to source code
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Usage examples via UI and CLI
- Detailed explanation of workflow steps
- Common use cases and troubleshooting
- Security and monitoring information
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Allows comparing any two versions via workflow_dispatch
- Accepts version inputs (e.g., 1.29.0 and 1.30.2)
- Validates version format and tag existence
- Generates changelog and uploads as artifact (90-day retention)
- Optional PR creation for updating docs/API-CHANGELOG.md
- Provides detailed summary in workflow output
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Removes the wait-for-ci job that has been causing random workflow skips
and reliability issues due to race conditions with CI check creation.
Multiple attempts to fix timing issues have resulted in ongoing edge
cases, so this simplifies the workflow to run immediately when the
claude-review label is added. Reviews can now run in parallel with CI
checks, and while they may occasionally run on PRs with failing CI, the
review feedback is often valuable regardless of CI status.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6548-fix-Remove-unreliable-CI-wait-logic-from-Claude-review-workflow-29f6d73d36508125910ef4feba5abdf4)
by [Unito](https://www.unito.io)
## Summary
Removes the `assignees` field from the weekly-docs-check workflow that
was causing failures.
## Problem
The workflow was attempting to assign `${{ github.repository_owner }}`
to created PRs. For organization-owned repositories,
`github.repository_owner` is the organization name (e.g., "Comfy-Org"),
which cannot be assigned to pull requests. Only individual GitHub users
can be assigned.
This was causing the workflow to fail:
https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18901589988
## Solution
Removed the `assignees` line from the workflow configuration. The PRs
will still be created successfully, just without auto-assignment.
## Changes Made
- Removed `assignees: ${{ github.repository_owner }}` from
`.github/workflows/weekly-docs-check.yaml:145`
Fixes#6364🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6375-fix-Remove-assignees-from-weekly-docs-check-workflow-29b6d73d365081769ec2dc3e68005cc7)
by [Unito](https://www.unito.io)
- Set PR base to current branch (github.ref_name) when triggered by push
- Keeps main as base for workflow_run triggers
- Allows testing on feature branches without conflicts with main
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Clean up scripts/snapshot-api.js and scripts/compare-api-snapshots.js before checkout
- Fixes untracked working tree files conflict when returning to current version
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Copy snapshot and comparison scripts to /tmp before checking out previous version
- Restore scripts after checkout to ensure they're available in older versions
- Fixes MODULE_NOT_FOUND error when running snapshot on previous versions
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Add push trigger for sno-api-changelog branch to allow testing
- Update job condition to handle both workflow_run and push events
- Limit version comparison to two most recent versions for efficiency
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
## Summary
- Updated weekly-docs-check.yaml to use `PR_GH_TOKEN` secret instead of
`GITHUB_TOKEN`
## Problem
The weekly documentation check workflow uses `GITHUB_TOKEN` when
creating pull requests, which can cause permission issues. The default
`GITHUB_TOKEN` has limited permissions and may not trigger other
workflows or perform certain PR operations.
## Solution
Changed the token in the "Create or Update Pull Request" step from
`secrets.GITHUB_TOKEN` to `secrets.PR_GH_TOKEN` to use a more permissive
token that can properly create and manage PRs.
## Changes Made
- `.github/workflows/weekly-docs-check.yaml:135` - Updated token
parameter
## Test Plan
- Workflow should now successfully create PRs with proper permissions
- Other workflows should be triggered correctly when PRs are created
🤖 Generated with [Claude Code](https://claude.com/claude-code)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6364-fix-Use-PR_GH_TOKEN-instead-of-GITHUB_TOKEN-in-weekly-docs-check-workflow-29b6d73d3650812cbaddc1ea10aeb995)
by [Unito](https://www.unito.io)
Co-authored-by: Claude <noreply@anthropic.com>
## Summary
Adds a new automated workflow that runs weekly to check and update
documentation accuracy.
## Changes
- Created `.github/workflows/weekly-docs-check.yaml`
- Workflow runs every Monday at 9 AM UTC or via manual dispatch
- Uses Claude to fact-check all documentation against the current
codebase
- Automatically creates/updates a draft PR with documentation
corrections
## Workflow Features
1. **Schedule**: Runs weekly (Mondays at 9 AM UTC) or on-demand via
workflow_dispatch
2. **Documentation Review**: Claude analyzes:
- All markdown files in `docs/`
- Project guidelines in `CLAUDE.md`
- README files throughout the repository
- Claude command documentation in `.claude/commands/`
3. **Automated PR Creation**: Uses `peter-evans/create-pull-request`
action to:
- Create or update the `docs/weekly-update` branch
- Generate a draft PR with all documentation updates
- Apply `documentation` and `automated` labels
## Benefits
- Keeps documentation synchronized with code changes
- Identifies outdated API references and deprecated functions
- Catches missing documentation for new features
- Ensures code examples remain valid and tested
## Test Plan
- [x] YAML syntax validated
- [ ] Workflow can be manually triggered to verify functionality
- [ ] PR creation works as expected
🤖 Generated with [Claude Code](https://claude.com/claude-code)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6298-feat-add-weekly-documentation-accuracy-check-workflow-2986d73d365081d48ce0f4cf181c377f)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Follow up on https://github.com/Comfy-Org/ComfyUI_frontend/pull/6317:
Fixes confusing "merge conflicts detected" message when commit already
exists on target branch (e.g., PRs #6294 and #6307).
## Changes
- Added check to detect if merge commit already exists on target branch
before attempting cherry-pick
- New failure reason `already-exists` for this case
- Clear comment message: "Commit already exists on branch, no backport
needed" instead of confusing "Merge conflicts detected" with empty file
list
## Before
When a commit already existed on the target branch, users would see:
> @user Backport to `core/1.30` failed: Merge conflicts detected.
> Please manually cherry-pick commit `abc123` to the `core/1.30` branch.
> <details><summary>Conflicting files</summary>
>
> </details>
This was confusing because there were no actual conflicts - the commit
was already present.
## After
Users now see:
> @user Commit `abc123` already exists on branch `core/1.30`. No
backport needed.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6326-ci-leave-comment-and-abort-early-if-commit-already-exists-on-target-branch-in-backport-w-2996d73d36508167aff3e6783e832c74)
by [Unito](https://www.unito.io)
Changes the RC minor version branch release automation to create paired
`core/x.y` and `cloud/x.y` branches whenever a release bump merges.
Then changes the backport workflow to accept labels that match those
branch names directly, allowing engineers to route fixes to either OSS
or cloud release lines without extra labels or artifacts.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6321-ci-automate-cloud-release-branch-tagging-2996d73d365081b0b036ebd3f088354b)
by [Unito](https://www.unito.io)
## Summary
Expands the wait step in `pr-claude-review.yaml` so the
`lewagon/wait-on-check-action` accepts every terminal GitHub conclusion
instead of failing on outcomes like cancelled or failure. After the wait
completes, the `check-status` script still inspects those check runs and
only marks `should-proceed=true` when the tracked jobs finished
successfully.
Fixes what happened here:
https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18828179272/job/53714488799?pr=6298
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>
Implements a GitHub Actions workflow that automatically generates API
changelogs by comparing TypeScript type definitions between versions.
Changes:
- Add release-api-changelogs.yaml workflow triggered after npm types release
- Create snapshot-api.js script to extract API surface from TypeScript defs
- Create compare-api-snapshots.js to generate human-readable changelogs
- Initialize docs/API-CHANGELOG.md to track public API changes
The workflow:
1. Triggers after Release NPM Types workflow completes
2. Builds and snapshots current and previous API surfaces
3. Compares snapshots to detect additions, removals, and modifications
4. Generates formatted changelog with breaking changes highlighted
5. Creates draft PR for review before merging
This automates documentation of breaking changes for extension developers
without manual effort, supporting the large extension ecosystem.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.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).
## 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)
