chore: remove repos from integrations.settings column for github and github-nango integrations (CM-963)

[themarolt]

Note

Medium Risk
Includes a data migration and broad changes to GitHub/GitHub-Nango integration flows and workers to source repos from public.repositories, which could impact onboarding, mapping, and run processing if assumptions diverge or data is missing.

Overview
Moves GitHub repo source-of-truth out of integrations.settings and into public.repositories. A new migration backs up existing settings and removes orgs[].repos plus top-level repos/unavailableRepos for github and github-nango integrations.

Adds compatibility layers so existing API/worker contracts still see settings.orgs[].repos. IntegrationRepository._populateRelations now hydrates orgs[].repos from public.repositories (and strips legacy keys), and the data-access layer adds helpers like getReposForGithubIntegration, populateGithubSettingsWithRepos, and stripReposFromGithubSettings.

Updates integration logic to stop writing repos back to settings. GitHub-Nango connect/mapping now strips repos before persisting settings, preserves forkedFrom via a map built from settings/DB, strips repo data from settings after syncing to public.repositories, and triggers onboarding runs only after transaction commit; progress and “update installed repos” paths now read repos from the repositories table.

Propagates the new repo lookup across services and tooling. Cron/worker/nango jobs switch from settings.orgs[].repos to public.repositories (injecting repos into settings when needed), GitHub integration stream processing only persists unavailableRepos, GitHub settings types mark repo fields as deprecated, the admin integrations page computes useGitHubNango dynamically, and the CLI gains a reset-and-restart command that restores previously running services.

^{Written by Cursor Bugbot for commit 49592d2. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[cursor]

New repos lose forkedFrom data in repositories table

Medium Severity

In connectGithubNango, a forkedFromMap is correctly extracted from incoming settings before repos are stripped. This map is passed to mapGithubRepos, but it's never propagated to buildRepositoryPayloads. Instead, buildRepositoryPayloads builds its own forkedFromMap by querying getReposForGithubIntegration from the repositories table — which is empty for new repos that haven't been inserted yet. All new repos therefore get forkedFrom: null. The subsequent syncGithubRepo workflow's upsertRepository sees the repo already exists and does a no-op, so the correct forkedFrom from the GitHub API is never written. The git integration worker relies on forkedFrom to detect forks and ensure parent repos are processed first.

Additional Locations (1)

• backend/src/services/integrationService.ts#L805-L838