Capability matrix: Go column shows 0% because the deploy workflow cannot read the internal `supabase-go` repo

[QuintinWillison]

🤖 AI-authored issue...

On https://supabase.github.io/sdk/ every cell in the Go column renders as ⬜ (not implemented) and the Go SDK card shows 0% coverage. The published data file at https://supabase.github.io/sdk/compliance.json contains no go key under compliance at all, and parity.perLanguage.go is 0.

This under-reports reality: supabase/supabase-go carries a populated sdk-compliance.yaml at its repository root on the default branch, currently declaring 42 feature entries.

Root cause

supabase/supabase-go is private and the Pages deploy workflow's token cannot see it:

1. The aggregator registers the repo (aggregate.ts:23) and fetches its sdk-compliance.yaml through the REST contents API, treating HTTP 404 as "file absent, skip this SDK" (aggregate.ts:32-45).
2. That call authenticates with the workflow's own token (capability-matrix-deploy-pages.yml:46-49). Per GitHub's docs: "The token's permissions are limited to the repository that contains your workflow."
3. For a private resource the caller cannot access, the REST API deliberately answers 404 rather than 403. Per GitHub's docs: "GitHub uses a 404 Not Found response instead of a 403 Forbidden response to avoid confirming the existence of private repositories."
4. Aggregation therefore logs go: no sdk-compliance.yaml found in supabase/supabase-go — skipping (visible in any recent "Deploy capability matrix site" run) and emits no go entry, so the site renderer falls back to not_implemented for every Go cell (generate-site.ts:69) and parity scores Go at zero.

The other six repos in the aggregation list are public, which is why their columns populate. Making supabase-go public is a product decision out of scope for this issue, so the realistic choices are the two below.

Option 1: feed the column with a cross-repo read token

Create a fine-grained PAT (or a GitHub App installation) granting contents: read on supabase/supabase-go, store it in this repo as e.g. SDK_COMPLIANCE_READ_TOKEN and let the aggregate step prefer it:

       - name: Aggregate compliance data from SDK repos
         env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          GITHUB_TOKEN: ${{ secrets.SDK_COMPLIANCE_READ_TOKEN || secrets.GITHUB_TOKEN }}
         run: npm run aggregate

An unset secret evaluates to an empty string, which is falsy in workflow expressions, so token-less runs and forks keep today's behaviour. If the token ever lapses, aggregation just skips Go again and the column reverts to grey rather than the deploy failing.

Pros: the column reflects reality within a day via the existing nightly cron, and the mechanism covers any future private SDK repo.

Cons: the implementation status of a private, unreleased SDK becomes world-readable, both on the site and through compliance.json, which the deploy publishes by design as machine-readable public data. The token also needs an owner, a rotation story and org-level allowance of fine-grained PATs (a GitHub App avoids token expiry at the cost of more setup). If publishing progress before launch is unacceptable, this option is out.

Option 2: deliberately defer until the repo is public

No token and nothing private gets published. The column stays empty until supabase-go goes public, at which point aggregation starts working with no further changes, exactly as it does for the six public repos today.

Con: the interim rendering is actively misleading, since ⬜ across the board plus 0% reads as "this SDK exists and has implemented nothing" rather than "no published data". If we choose this we should consider making the absence honest, either by hiding the Go column until launch or by rendering a distinct "no data" state. Note the columns derive from the LANGUAGES enum (types.ts:1-10), which compliance validation also depends on (compliance.ts:44), so hiding the column means introducing a separate display list rather than deleting the enum entry.

Decision needed

Which option do we want? If Option 2 wins, the follow-on question is whether the interim rendering should distinguish "no published data" from "not implemented".

Or, perhaps even, should the column just disappear?