<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=628586) </details> <!--IssueSummary end--> ## Why The GitHub continuous sync feature already exists as a working proof of concept in merge request [!251883](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/251883) (`Draft: POC - Import GitHub repositories with continuous sync`, branch `feature/github-connected-project-poc`). That MR is about 40,000 lines and was never code-reviewed. Rather than merge it as-is, we're closing that MR for good and porting its pieces into `master` as a series of small merge requests that reviewers can actually read. This issue ports the layer that turns one repository a user picked into a real GitLab project. By the time this code runs, https://gitlab.com/gitlab-org/gitlab/-/work_items/628585 has already proven the user's GitHub App installation is valid; this layer's job is to resolve and authorize that one request, then create the project and kick off the existing GitHub importer. Everything in this MR lands behind the `github_continuous_import` feature flag (type `wip`, default off, created in https://gitlab.com/gitlab-org/gitlab/-/work_items/628579), so it has no effect on any real project until later work turns it on. A scope audit on 2026-09-10 dropped the grant credential this layer used to issue. The PoC's design had the browser prepare a batch of repositories (`PrepareImportService`), get back a short-lived, single-use, session-bound credential per repository (an `ImportGrant`), and redeem each one separately (`ConsumeImportGrantService`) to actually create the project. That whole mechanism is dropped, not simplified: `PrepareImportService`, `ConsumeImportGrantService`, `ImportGrantToken`, `ContinuousImportsController` and its `/github/continuous_imports/*` routes, and the `continuity_import_grant_optional_stages.json` schema are not ported by this issue or any other. In its place, `Import::GithubController#create` (ported in https://gitlab.com/gitlab-org/gitlab/-/work_items/628592, along with the rest of that controller and its frontend) takes one request per selected repository, with a `continuous_sync` flag. This issue lands the services that request calls: the server resolves the App installation covering that repository directly against GitHub (`AppApiClient#repository_installation`, the App JWT `GET /repos/:owner/:repo/installation`, landed in https://gitlab.com/gitlab-org/gitlab/-/work_items/628583), verifies it through `CurrentInstallationVerifier` (adapted in https://gitlab.com/gitlab-org/gitlab/-/work_items/628585 to take an installation ID instead of a connection, since there's no connections table any more), checks `can?(current_user, :import_projects, namespace)`, and creates the project through `ConnectedProjectCreator`/`ProvisionService` and `ConnectedGithubImportService`, which write the installation fields (`provider`, `provider_installation_id`, `provider_account_id`, `provider_account_login`) onto the new `Import::Sync::Repository` row alongside the repository's own provider fields. If no installation covers the repository, the response is `github_app_access_required` plus the install URL from `StartAppSetupService` (https://gitlab.com/gitlab-org/gitlab/-/work_items/628585), so the page can show an "Install the GitHub App" link. There's no batch, no resume flow, and no credential to double-spend: each request is authorized and created in one pass, the same shape as the existing (non-connected) `Import::GithubController#create` path already uses. `Import::GithubController` itself belongs to https://gitlab.com/gitlab-org/gitlab/-/work_items/628592, which lands the controller and the frontend together. This issue only needs to land the services https://gitlab.com/gitlab-org/gitlab/-/work_items/628592's `create` action will call; if whoever picks up this issue would rather add the `continuous_sync` branch to the controller here too (so the services aren't landed without a caller), that's fine, just say so in the MR description. ## What to do Read the files listed below and port them into a fresh MR against `master`, renaming `Continuity::Github::X` to `Import::Sync::Github::X` and `Continuity::Projects::X` to `Import::Sync::Projects::X`. **`RepositoryResolver#adapter_class`** currently picks between two implementations: a `FixtureRepositoryResolver` for the offline simulator, and `InstallationRepositoryResolver` for real GitHub, which itself walked a GitHub account's existing `Connection` rows. Neither survives: the simulator isn't being ported, and `InstallationRepositoryResolver` isn't either, now that there's no connections table for it to search (decided 2026-09-11; see https://gitlab.com/gitlab-org/gitlab/-/work_items/628585). Drop the `adapter_class`/`adapter_arguments` indirection and the `configuration.test_mode?` checks around it entirely, and fold what `InstallationRepositoryResolver` used to do straight into `RepositoryResolver`: call `AppApiClient#repository_installation(full_name)` to ask GitHub which installation covers the repository, then `CurrentInstallationVerifier` (adapted in https://gitlab.com/gitlab-org/gitlab/-/work_items/628585 to take an installation ID) to confirm it's active with the required permissions. See the resolution paragraph below for the full flow. **`ImportTarget` and `RepositoryIdentity` are still needed, but `ImportTarget` loses a method.** Both value objects predate the grant and don't depend on it: `RepositoryIdentity` is what `RepositoryResolver`/`InstallationRepositoryResolver` parse a GitHub API repository response into, and `ImportTarget` is what normalizes and validates one request's `repo_id`/`new_name`/`target_namespace`/`optional_stages` before it's resolved. Port both. Drop `ImportTarget#matches?`, which exists only to compare a normalized request against a persisted grant's bound values; there's no grant left for it to compare against. **`ProvisionService` becomes resolve-and-authorize, not consume-a-grant.** Where the PoC's `ProvisionService` called `ConsumeImportGrantService` to atomically redeem a token, port a version that does the same authorization work directly, for the one target in the request: parse it with `ImportTarget`, resolve the destination namespace, check `can?(current_user, :import_projects, destination_namespace)`, resolve the repository through `RepositoryResolver` (which now always resolves directly against GitHub via `AppApiClient#repository_installation` and `CurrentInstallationVerifier`, see above), and if it resolves to `ready`, hand off to `ConnectedGithubImportService`/`ConnectedProjectCreator` exactly as the PoC does after a successful grant consumption. Every other resolution status (`github_app_access_required` and friends) is returned to the caller unchanged, so https://gitlab.com/gitlab-org/gitlab/-/work_items/628592's controller can show the same recovery messaging the PoC's grant path did. **How a repository finds its installation now that there's no connections table.** The PoC's `InstallationRepositoryResolver`, which walked existing `Connection` rows for the repository's account, and the dropped `AppUserInstallationEnrollmentService`, which covered the case where the App was installed on GitHub but no local connection existed yet, are both gone: there's nothing left to look up locally, since the installation fields no longer live on a standalone row. Resolution is now a single path: `AppApiClient#repository_installation(full_name)` calls `GET /repos/:owner/:repo/installation` (the PoC uses it only in the dropped `ReconnectService`) to ask GitHub directly which installation covers the repository, then `CurrentInstallationVerifier` (adapted in https://gitlab.com/gitlab-org/gitlab/-/work_items/628585 to take an installation ID) confirms it's active with the required permissions. If GitHub reports no installation, or the one it reports isn't active or lacks the required permissions, return `github_app_access_required` with the install URL from `StartAppSetupService` (https://gitlab.com/gitlab-org/gitlab/-/work_items/628585). On success, `RepositoryResolver` returns `ready` and `ConnectedProjectCreator` creates the project and the `Import::Sync::Repository` row in the same pass, copying `provider`, `provider_installation_id`, `provider_account_id`, and `provider_account_login` onto it from the installation GitHub returned, along with the repository's own `provider_repository_id`, `provider_repository_node_id`, `provider_full_name`, and `provider_default_branch`. There's no enrollment step and no local candidate list to consult first. **Two test-mode branches to remove.** `ProvisionService#execute` returns `provision_with_test_provider(consumed)` when the connection is in test mode, and takes a `test_provider_adapter:` constructor argument for it. `ConnectedProjectCreator#verify_provider_access!` includes `!current_connection.test_mode?` in its check. Delete both; the `test_mode` column does not exist after https://gitlab.com/gitlab-org/gitlab/-/work_items/628581, and `current_connection` itself is gone too, now that `verify_provider_access!` re-checks an installation rather than a `Connection` (see below). The matching examples in `provision_service_spec.rb` go too. **`BootstrapMutationBarrier` and `LifecycleMutationBarrier` are not ported.** Both are PostgreSQL advisory-lock classes; neither is ported by https://gitlab.com/gitlab-org/gitlab/-/work_items/628582 or anywhere else. They hold a session-level `pg_advisory_lock` across a transaction and network calls, and GitLab requires PgBouncer in transaction pooling mode (`doc/administration/postgresql/pgbouncer.md`, line 247), under which a session lock taken on one backend connection can't reliably be released on another and can leak. Everywhere the PoC locks against one of them, this issue ports a row lock plus an `application_generation` compare instead: - `CancelBootstrapService` and `FailBootstrapService` both wrap their work in `BootstrapMutationBarrier.new(repository.id).with_exclusive`. Drop that wrapper; keep everything inside it as-is, since both services already take `import_state.lock!` and `repository.lock!` row locks inside a transaction, and both already keep the `ApplicationLease` (ported, simplified, in https://gitlab.com/gitlab-org/gitlab/-/work_items/628582) around that transaction. The row locks plus the lease are the fence; the barrier wrapper added nothing these two services don't already have. - `ConnectedProjectCreator#lifecycle_barrier` builds a `LifecycleMutationBarrier` and takes it `with_shared` around `verify_provider_access!` and project creation, to serialize a create against a concurrent lifecycle mutation on the same `Connection` row. There's no `Connection` row to lock any more (decided 2026-09-11), so drop `lifecycle_barrier` entirely rather than replacing it with a row lock: `verify_provider_access!` re-checks the installation live via `CurrentInstallationVerifier` immediately before creating the project (a fresh API-backed check, not a re-read-under-lock, since the installation's state lives on GitHub, not in a row this service can lock), and the partial unique index on `(organization_id, provider_repository_id)` from https://gitlab.com/gitlab-org/gitlab/-/work_items/628581 is what stops two concurrent creates for the same GitHub repository from both succeeding: the second one hits the constraint and should be handled as a conflict, not retried blindly. Call out this design in the MR description, so the reviewer knows the concurrency guard moved from a lock to a live check plus a database constraint. - `app/services/import/github/cancel_project_import_service.rb` rescues `Continuity::Repositories::BootstrapMutationBarrier::FailedToAcquireError` and maps it to a "try canceling again" conflict response. Drop that rescue clause; there's no bounded-timeout barrier left to raise it. The other rescues (`ImportCompletedError`, `InvalidAuthorityError`) are unaffected and port as-is. Nothing here calls into a layer that hasn't landed by the time this MR merges. **Retire provider authority for a canceled or terminally failed import.** Port `cancel_bootstrap_service.rb` and `fail_bootstrap_service.rb`, both transactional and idempotent, both locking the import state and the repository row (`import_state.lock!`, `repository.lock!`) before touching them, without the `BootstrapMutationBarrier` wrapper (see above). `CancelBootstrapService#execute` locks the import state and the repository, confirms the import isn't already complete and the repository is still `provisioning?` or `provider_canonical?`, then cancels the import, flips `authority_state` to `bootstrap_canceled`, bumps `application_generation`, and pauses every sync-state row with a `github_import_canceled` error. `FailBootstrapService.retire_for_provider_access_loss` is the entry point `DisconnectForProviderAccessLossService` (https://gitlab.com/gitlab-org/gitlab/-/work_items/628589) will call later; `#execute` itself handles the terminal-failure cases (an import that failed, finished its handoff, or was canceled while still provisioning) by marking the import failed if it isn't already terminal, then retiring provider authority the same way `CancelBootstrapService` does, but treats an import that's already `bootstrap_canceled` and terminal, or one that's still an active `provider_canonical?` connection, as nothing to do. Carry over the named spec examples from the PoC, rewritten to assert the row-lock-plus-generation behavior instead of barrier behavior where they touched it: `cancel_bootstrap_service_spec.rb`'s "when catch-up won the authority race but the importer remains cancelable" and "does not retire the association after the import completed concurrently"; `fail_bootstrap_service_spec.rb`'s "when importer completion and catch-up both won the race". These are the examples that prove the two services don't double-retire or clobber a concurrent catch-up. ## PoC files to read `app/services/continuity/github/`: - `import_target.rb` (drop `matches?`, see above) - `repository_identity.rb` - `repository_resolver.rb` `app/services/continuity/projects/`: - `connected_github_import_service.rb` - `connected_project_creator.rb` - `provision_service.rb` (rework around `ConsumeImportGrantService`'s logic, see above; read that file too even though it isn't ported, since `ProvisionService`'s replacement needs to inline its preflight checks) `app/services/continuity/repositories/`: - `cancel_bootstrap_service.rb` - `fail_bootstrap_service.rb` Also: - `app/services/import/github/cancel_project_import_service.rb` (see the dependency note above before touching it). - `app/controllers/import/github_controller.rb` (diff against `origin/master`), for context on the shape of the `continuous_sync` request https://gitlab.com/gitlab-org/gitlab/-/work_items/628592 will send: the `continuous_import_requested?`/`continuous_import_available?` checks and the `execute_continuous_import` call into `ProvisionService`. This is read-only context; the controller change itself is https://gitlab.com/gitlab-org/gitlab/-/work_items/628592's. Do not port `prepare_import_service.rb`, `consume_import_grant_service.rb`, `import_grant_token.rb`, `app/controllers/continuity/github/continuous_imports_controller.rb`, or `app/validators/json_schemas/continuity_import_grant_optional_stages.json`; none of them is part of this port (see above). Also skip the `/github/continuous_imports/*` entries in the `config/routes.rb` diff. Specs: the matching files under `spec/services/continuity/github/` (for `import_target.rb`, `repository_identity.rb`, `repository_resolver.rb`) and `spec/services/continuity/projects/`, and `spec/services/continuity/repositories/{cancel_bootstrap_service,fail_bootstrap_service}_spec.rb`, plus `spec/services/import/github/cancel_project_import_service_spec.rb`. `provision_service_spec.rb` needs the most rework: its grant-consumption setup becomes direct resolve-and-authorize setup, and its `matches?`-dependent examples go with `ImportTarget#matches?`. Note that `import_target.rb` doesn't have its own spec file in the PoC; it's covered indirectly through the specs for the services that use it. ## Acceptance criteria - All the classes listed above are merged to `master` under their new names, and existing specs pass. - `RepositoryResolver#adapter_class` and its supporting methods no longer exist; the resolver calls `AppApiClient#repository_installation` and `CurrentInstallationVerifier` directly, with no `InstallationRepositoryResolver` or `FixtureRepositoryResolver` in between. - No `ImportGrant`, `PrepareImportService`, `ConsumeImportGrantService`, `ImportGrantToken`, `ContinuousImportsController`, `InstallationRepositoryResolver`, `InstallationService`, or `Connection` reference remains anywhere in this layer or its specs. - A connected import creates exactly one project per request, and only when an active installation with the required permissions covers the repository and the requesting user can import into the destination namespace. When no such installation covers the repository, the response is `github_app_access_required` with an install URL. - `Import::Sync::Repository` rows created by this layer carry the installation fields (`provider`, `provider_installation_id`, `provider_account_id`, `provider_account_login`) copied from the `AppApiClient#repository_installation` response, not looked up from a connection. - The non-connected `Import::GithubController#create` path is unchanged by this MR. - No `test_mode?` or `test_provider_adapter` reference remains in this layer or its specs. - `cancel_project_import_service.rb`'s call to `CancelBootstrapService` is ported as-is and passes against the version of `CancelBootstrapService` landed in this same MR; its rescue of `BootstrapMutationBarrier::FailedToAcquireError` is dropped, since that class no longer exists. - `cancel_bootstrap_service_spec.rb` and `fail_bootstrap_service_spec.rb` pass, including the named examples carried over from the PoC. - No reference to `BootstrapMutationBarrier` or `LifecycleMutationBarrier` remains anywhere in this layer or its specs. ## Out of scope - `PrepareImportService`, `ConsumeImportGrantService`, `ImportGrantToken`, `ContinuousImportsController`, and the `continuity_import_grant_optional_stages.json` schema. Dropped entirely, not ported by this or any other issue (see above). - The rest of the lifecycle layer: `ApplyLifecycleEventService` and the other lifecycle transitions that used `LifecycleMutationBarrier` in the PoC are https://gitlab.com/gitlab-org/gitlab/-/work_items/628589, ported the same way (a repository row lock plus a generation compare, fanned out across every repository row sharing the installation's `provider_installation_id`, since there's no connection row to lock instead). - `Import::GithubController` and its frontend, including the `continuous_sync` request/response handling this issue's services are built for (https://gitlab.com/gitlab-org/gitlab/-/work_items/628592). - The offline GitHub simulator. It isn't ported by any issue. - Any change to the existing (non-connected) GitHub Importer path. This layer only adds a new way to reach the same importer; it doesn't change how the importer itself behaves. ## Notes for the reviewer - `ConnectedProjectCreator#verify_provider_access!` re-checks the installation live against GitHub, right before creating the project, rather than re-reading a `Connection` row under a lock (there is none any more). This is a deliberate second check, not a redundant one: it closes the gap between resolving the repository and actually creating the project, in case the installation was suspended or removed in between. With no grant left to also re-check at consumption time, this live re-verification is now the only thing closing that gap; confirm it's still there and still runs immediately before project creation, not earlier in the request. - Since there's no grant, there's no double-spend to test for. The interesting concurrency question here is narrower: two simultaneous `continuous_sync` requests for the same repository (from a retried request, or two tabs) shouldn't both create a project. With the connection row lock gone (see above), the partial unique index on `(organization_id, provider_repository_id)` from https://gitlab.com/gitlab-org/gitlab/-/work_items/628581 is what prevents that; confirm `ConnectedProjectCreator` handles the constraint violation as a conflict rather than letting it surface as an unhandled exception, and consider a spec that exercises it.