Summary

This PR refactors CI workflows to use shared reusable workflows from the supabase/actions repository, standardizing patterns across all Supabase repositories.

Changes

Workflows Refactored to Use Reusable Actions

1. block-merge.yml (Simplified from 35 to 12 lines)

Before: Inline implementation with GitHub Script
After: Uses supabase/actions/.github/workflows/block-merge.yml@feat/reusable-workflows

Functionality preserved:

• Blocks draft PRs
• Blocks PRs with do-not-merge label
• Blocks PRs with wip or do not merge in title

2. label-issues.yml (Simplified from 107 to 26 lines)

Before: Complex inline script handling transfers, templates, and PR titles
After: Uses supabase/actions/.github/workflows/label-issues.yml@feat/reusable-workflows

Functionality preserved:

• Extracts scope from conventional commit PR titles (e.g., fix(auth): → auth-js label)
• Parses issue templates for affected modules
• Supports all package labels: auth-js, functions-js, postgrest-js, storage-js, realtime-js, supabase-js

Note: Transfer detection and detailed template parsing are simplified in the reusable workflow. If these features are critical, we can enhance the reusable workflow.

Workflows Kept As-Is

stale.yml

Kept unchanged - has sophisticated multi-tier stale handling specific to this repository:

• Fast track for "needs more info" and "retry with latest" labels
• Different timelines for different issue categories
• More complex than the generic reusable workflow

slack-notify.yml

Kept unchanged - already a reusable workflow hosted in this repo:

• Uses repo-specific secrets (SLACK_CLIENT_LIBS_WEBHOOK)
• Called by other workflows in this repository
• Different from supabase/actions version which is for cross-repo use

Other Workflows

No changes to:

• ci.yml, ci-core.yml, ci-supabase-js.yml - Repo-specific CI logic
• docs.yml - Monorepo documentation generation
• publish.yml - Package publishing with npm provenance
• preview-release.yml - Preview releases for PRs
• fix-lockfile.yml - Dependabot lockfile regeneration

Benefits

Maintainability

• Single source of truth: Workflow logic maintained in one place
• Easier updates: Bug fixes and improvements benefit all repos automatically
• Less duplication: Reduced from 142 lines to 38 lines (-73%)

Consistency

• Same behavior across supabase-swift, supabase-js, and future Supabase repos
• Standardized error messages and user experience
• Consistent label mappings and conventions

Future-Proof

• New features in reusable workflows automatically available
• Can pin to specific versions for stability: @v1 or @commit-sha
• Easier to test workflow changes (test in supabase/actions, then deploy everywhere)

Testing

To verify functionality:

• block-merge: Create draft PR or PR with "do-not-merge" label → should be blocked
• label-issues: Create PR with conventional commit title → should get appropriate label
• label-issues: Create issue with module checkbox → should get appropriate label

Migration Notes

For Maintainers

After merge, workflows will use the branch feat/reusable-workflows until supabase/actions PR #1 is merged to main. Once merged, update references to use @main or a specific version tag.

Rollback Plan

If issues arise, can easily revert to previous inline implementations by reverting this PR.

Related PRs

• Reusable Workflows: feat: add reusable GitHub Actions workflows actions#1
• supabase-swift Adoption: feat(ci): enhance CI with format check, API stability, and success summary supabase-swift#887

Breaking Changes

None. External behavior is identical.

Future Work

Potential future consolidations:

1. Consider using reusable stale workflow with custom configurations for different label categories
2. Evaluate other workflows for potential standardization (docs, release notifications)
3. Pin to stable version tags once supabase/actions establishes versioning

Co-Authored-By: Claude Sonnet 4.5 noreply@anthropic.com