chore(repo): remove transitional scripts/ compatibility symlinks - #102
Merged
Conversation
The packages/ restructure left scripts/capability-matrix and scripts/dart_symbol_extractor as symlinks into packages/, so SDK repos pinned to pre-restructure refs kept working. All callers now pin v1.3.0 or track main, so the symlinks have no consumers. Also drops the now-stale scripts/ entry from the README layout block and the corresponding CLAUDE.md paragraph, and rewords the sdk-ref input descriptions that still said "for scripts".
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
spydon
marked this pull request as ready for review
August 27, 2026 14:46
QuintinWillison
approved these changes
Aug 28, 2026
spydon
added a commit
that referenced
this pull request
Aug 28, 2026
… SHA (#107) ## What Restructures the five reusable `validate-sdk-compliance-*` workflows so that the composite actions and the capability spec are resolved from the single supabase/sdk commit the caller pinned the workflow at (`job.workflow_sha`), instead of being referenced remotely by a hardcoded SHA or `@main`. Each job now checks out supabase/sdk once into `_sdk-spec` at `inputs.sdk-ref || job.workflow_sha` and references the actions locally (`./_sdk-spec/.github/actions/...`). The actions' own spec checkouts become transitional no-ops when `sdk-ref` is empty. ## Why The supabase-go compliance job broke on every PR ([example run](https://github.com/supabase/supabase-go/actions/runs/33156922333/job/98801800438?pr=55)): ``` An error occurred trying to start process '/usr/bin/bash' with working directory '.../_sdk-spec/scripts/capability-matrix'. No such file or directory ``` Root cause: `validate-sdk-compliance-go.yml` pins its composite actions to the v1.2.0 SHA (`29e402da`), whose steps still use the pre-monorepo `scripts/capability-matrix` paths, while the actions check out the spec at `sdk-ref` defaulting to `main`. #93 restructured the repo into `packages/` with compatibility symlinks, and #102 removed the symlinks, so the frozen action code and the floating spec checkout diverged. `uses:` cannot carry an expression, so a reusable workflow cannot remotely reference its sibling actions at its own SHA. The Go workflow worked around that with a hardcoded previous-release SHA that #93 forgot to bump; the other language workflows used `@main`, which hides the same skew and defeats the callers' SHA pins. Checking the repo out at `job.workflow_sha` (the pattern `sync-sdk-compliance.yml` already uses) and referencing the actions locally removes the entire failure class: workflow, action code, and spec always come from one immutable commit. ## Compatibility - Consumers pinned to v1.3.0 and earlier keep working: those workflow versions reference the actions remotely and always pass a non-empty `sdk-ref`, which now triggers the actions' transitional self-checkout path (against `main`, whose layout matches). The transitional steps and the actions' `sdk-ref` inputs can be deleted once every consumer is on the new release. - `sdk-ref` on the workflows remains as an explicit override for pre-merge testing; its default changes from `main` to the called workflow's SHA. - supabase-go stays broken until it bumps: its pinned v1.3.0 Go workflow references the actions at the v1.2.0 SHA, which no ref can fix from the caller side alone. Pinning `sdk-ref: v1.3.0` there is the only stopgap. ## Follow-up after merge 1. Cut a release (v1.4.0) including this change. 2. Bump the reusable-workflow pins in supabase-go (dropping its `sdk-ref: main` override), then supabase-flutter, supabase-js, supabase-py, supabase-swift. 3. Once all consumers are bumped, remove the transitional `sdk-ref` handling from the two composite actions.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR removes the compatibility layer that pinned callers depend on. Merging it early breaks the compliance check on any SDK repo that has not yet bumped.
supabase-goalready tracks@mainand needs nothing.What
Removes the two transitional symlinks left behind by the
packages/restructure (#93):With both gone,
scripts/is empty and disappears.Follow-on cleanup of the same concept:
README.md— drops thescripts/entry from the repository layout block.CLAUDE.md— drops the paragraph explaining the symlinks and when to remove them.sdk-refinput descriptions (5 reusable workflows + 2 composite actions) — reworded from "Ref to checkout from supabase/sdk for scripts" to "... for tooling", sincescriptsno longer names anything. Description-only, not part of the call contract. Easy to drop from this PR if you would rather keep the diff to the symlinks alone.Why the symlinks existed
Pinning to these reusable workflows is not fully hermetic: the pinned workflow body comes from the tag, but the composite actions it calls are referenced
@mainand check out this repo atmain. After the restructure, a caller pinned tov1.2.0therefore combined a post-restructure checkout with a workflow body still hardcoding_sdk-spec/scripts/.... The symlinks bridged exactly that gap.v1.3.0was cut (#97, #98) to give callers a post-restructure ref to pin to, which is what the four PRs above do.Verification
npm run validate— OKnpm test— 195 passed (14 files)npm run typecheck— cleangit grep "scripts/"— no matches anywhere in the repoThe four caller PRs are the real proof: each one's own compliance run resolves the
packages/paths against amaincheckout, and all four passed.Note for later
This class of breakage recurs whenever a path referenced by a pinned workflow body moves, because the composite actions float on
@main. Pinning thesdk-compliance-*action refs alongside the workflow ref, or having the workflows resolve tooling paths dynamically, would make pinning actually hermetic. Out of scope here.