fix(ci): skip Link job on fork PRs

[lightstrike]

Summary

Skip the Link CI job on pull requests from forked repositories, where it always fails due to unavailable secrets.

Problem

The Link job requires SUPABASE_ACCESS_TOKEN and SUPABASE_PROJECT_ID repository secrets to run ./main link against a real Supabase project. GitHub Actions does not expose repository secrets to workflows triggered by fork PRs (this is a deliberate security measure).

As a result, every fork PR shows a persistent red Link failure in its CI checks. This is misleading for both contributors and reviewers — it creates the impression that something is broken when the PR's code is actually fine.

Fix

Add a single if condition to the Link job:

if: ${{ !github.event.pull_request.head.repo.fork }}

Behavior after this change:

Trigger	Link job
Push to develop	Runs normally (github.event.pull_request is null, so head.repo.fork is falsy)
PR from a branch within supabase/cli	Runs normally (not a fork)
PR from a fork	Skipped (shows as grey "skipped" instead of red "failed")

This is the standard GitHub Actions pattern for guarding jobs that depend on repository secrets.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

Configuration used: Central YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Pro

Cache: Disabled due to Reviews > Disable Cache setting

Disabled knowledge base sources:

• Linear integration is disabled

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 5726ec3 and 0dbe5e5.

📒 Files selected for processing (1)

• .github/workflows/ci.yml

---

📝 Walkthrough

Summary by CodeRabbit

• Chores
  • Updated CI/CD configuration to optimize workflow execution.

Walkthrough

The pull request adds a conditional guard to the Link job in the GitHub Actions CI workflow. The condition if: ${{ !github.event.pull_request.head.repo.fork }} prevents the Link job from executing when the pull request originates from a forked repository. This means the Link job will only run for pull requests from the main repository, while being skipped for all forked pull request submissions.

---

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 and usage tips.}

[lightstrike]

Context for reviewers: longer-term consideration

This PR is a targeted fix — skip the Link job on fork PRs where secrets are unavailable. It's worth noting the broader architectural questions here though.

The Link job was introduced in #4505 (Nov 2025) as a side-item alongside the fsevents mock work. It runs the full link command against a real remote Supabase project, validating authentication, the Management API surface (6 endpoints), tenant service discovery (3 endpoints), and local config file writes.

The reliance on repo secrets (SUPABASE_ACCESS_TOKEN / SUPABASE_PROJECT_ID) means fork PRs will never get coverage from this job. For a project that accepts external contributions, there are a few paths that could eliminate the gap:

1. Test against the local stack. The Start job already spins up a full Supabase instance via ./main start. The link command could be tested against localhost instead of a remote project, removing the need for secrets entirely.

2. Dedicated throwaway CI project. A free-tier project with no real data, where the project ref and a scoped access token are treated as non-sensitive and stored as regular env vars (not secrets). The blast radius of exposure is effectively zero.

3. Expanded unit/integration test coverage. internal/link/link_test.go already mocks API responses extensively. If the mocked tests cover the same surface the CI job validates, the real-project smoke test may be redundant — or at least not critical enough to gate PRs on.

None of this blocks merging the if: !fork fix here, though I believe it would be worth tracking as a follow-up so the Link job provides value to all contributors.