fix(ci): resolve compliance tooling and spec from the called workflow SHA

[spydon]

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):

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.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: bb496b54-6b6f-4ea3-a012-a82b0b1449a1

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}