2 Commits

Author	SHA1	Message	Date
Christian Byrne	d1639c4377	[ci] extend backport workflow to work with arbitrary branches (#6108) ... ## 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)	2025-10-17 14:38:06 -07:00
snomiao	8cc5b52c64	refactor: reorganize GitHub workflows with consistent naming convention (#5891) ... ## Summary This PR implements a systematic naming convention for all GitHub workflows to improve organization and discoverability. All 22 workflows have been renamed and grouped by logical categories with consistent prefixes. ## Changes ### Naming Convention - **`ci-*`**: Continuous Integration workflows (testing, linting, validation) - **`pr-*`**: PR-specific automation triggered by labels - **`release-*`**: Release management workflows - **`types-*`**: TypeScript type generation workflows - **`i18n-*`**: Internationalization workflows ### Key Renames - `tests-ci.yaml` → `ci-tests-e2e.yaml` - `vitest-tests.yaml` → `ci-tests-unit.yaml` - `storybook-and-chromatic-ci.yaml` → `ci-tests-storybook.yaml` - `auto-backport.yaml` → `pr-backport.yaml` - `claude-pr-review.yml` → `pr-claude-review.yaml` - `version-bump.yaml` → `release-version-bump.yaml` - `publish-frontend-types.yaml` → `release-npm-types.yaml` - `create-dev-pypi-package.yaml` → `release-pypi-dev.yaml` ### Test Workflow Improvements - Grouped all test workflows under `ci-tests-*` pattern - Fork-safe deployment workflows: `ci-tests-e2e-forks.yaml`, `ci-tests-storybook-forks.yaml` - Added comments explaining fork deployment security workarounds ### Documentation - Added comprehensive `.github/workflows/README.md` - Documents naming conventions, best practices, and workflow organization - Includes trigger patterns and external dependencies ## Benefits 1. **Better Organization**: Workflows are now grouped logically by prefix 2. **Improved Discoverability**: Easy to find related workflows 3. **Consistent Naming**: All workflows follow the same pattern 4. **Clear Purpose**: Workflow names immediately indicate their function 5. **Maintainable**: README provides guidelines for future workflows ## Test Plan - [x] All workflow cross-references updated - [x] Display names match new file names - [x] Fork deployment workflows properly reference main workflows - [x] Release workflows reference correct npm types workflow - [x] All workflows retain original functionality 🤖 Generated with [Claude Code](https://claude.ai/code) ┆Issue is synchronized with this [Notion page](https://www.notion.so/PR-5891-refactor-reorganize-GitHub-workflows-with-consistent-naming-convention-2806d73d365081febe47c7511bf0507e) by [Unito](https://www.unito.io) --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Alexander Brown <drjkl@comfy.org>	2025-10-17 08:32:33 +09:00