## Why Once a project is connected and syncing from GitHub, the customer needs a way to see that it's happening and to control it: check whether the repository and its issues/merge requests are up to date, ask for an update right now, or permanently stop updates and take the project back to ordinary read-write GitLab. Without this panel, sync would be invisible, and "stop updates" (which is irreversible) would have no safe, deliberate place to happen. This panel already exists and works in the proof of concept, merge request [!251883](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/251883) (branch `feature/github-connected-project-poc`). This issue ports it into a fresh MR against `master`, once its backend dependencies (webhooks/repair, stop/cutover, and read-only enforcement) are real, and simplifies it along the way. ## What to do Port `Projects::Continuity::GithubUpdatesController` as `Projects::Import::Sync::GithubUpdatesController`. It has three actions, all requiring the current user to be an admin of the project and 404ing if the project has no `import_sync_repository`: - `status` (GET), returns the current state as JSON: the overall authority state, whether the project is read-only, and, for each sync domain (repository content, and issues/merge requests), its state, when it last updated, and when it was last checked. - `update_now` (POST), asks for an immediate sync pass via the request-update service from a prior LAND issue, and returns the same status shape plus a "scheduled" message. Returns a specific error if the project isn't in a state where an update can be requested. - `stop` (POST), requires the request to include the project's full path, typed exactly, as confirmation. Calls the stop service and returns the same status shape plus a generation number. Maps specific failure conditions to distinct error responses: the repository disconnected from GitHub, wrong state to stop from, and the sync lease being busy with another in-progress operation. The PoC's `stop` action rescues both `Continuity::Repositories::ApplicationMutationBarrier::FailedToAcquireError` and `Gitlab::ExclusiveLeaseHelpers::FailedToObtainLockError` for that last case; `ApplicationMutationBarrier` isn't ported (see https://gitlab.com/gitlab-org/gitlab/-/work_items/628590), so drop that half of the rescue and keep only `Gitlab::ExclusiveLeaseHelpers::FailedToObtainLockError`, which the `ApplicationLease` used by `RequestStopService` still raises when it can't obtain the lease. Do not port `reconnect`. Drop the controller action, its route, and the `ReconnectService` it calls entirely. A 30-minute background lifecycle repair check already restores access automatically after a connection problem, so there's no need for a customer-triggered manual reconnect action in this port. (A later https://gitlab.com/gitlab-org/gitlab/-/work_items/628595 issue may add a "Check connection now" button and a "Manage GitHub App access" link as separate, smaller additions; this issue doesn't need to anticipate that, just make sure `reconnect` itself is gone.) Port `Continuity::ProjectsHelper` as `Import::Sync::ProjectsHelper` (included into the existing `ProjectsHelper`, a one-line change there), simplified to about 15 lines. It builds the GitHub repository URL for display from `project.import_sync_repository`'s `provider_account_login` and `provider_full_name`, decides whether to show the settings panel at all (hidden only when the repository's setup was cancelled before syncing started), and delegates to the write policy from https://gitlab.com/gitlab-org/gitlab/-/work_items/628591 to know whether legacy mirroring is currently blocked. Drop the five-variant `github_updates_read_only_notice` lookup (one title/body/variant hash per authority state); the read-only banner becomes one static alert instead (see the partials paragraph below). Port the route addition in `config/routes/project.rb` (a singular `github_updates` resource with `status`, `update_now`, and `stop` actions, renamed to match the new controller). On the frontend, port `constants.js`, which defines exactly six rendered overall states (`provisioning`, `provider_canonical`, `disconnected`, `cutting_over`, `cutover_failed`, `gitlab_canonical`, a project whose setup was cancelled before syncing ever started isn't rendered here at all, because the backend helper hides the whole panel for that case) and exactly seven per-domain sync states (`current`, `pending`, `running`, `delayed`, `degraded`, `paused`, `disconnected`), plus a 5-second polling interval, now consumed via `~/lib/utils/poll` rather than a raw interval (see below). Port `index.js` (mounts the Vue app from a `#js-github-updates-settings` element, reading its data attributes) and `status_utils.js` (turns a raw status response into the two fixed table rows: repository content, and issues/merge requests). Port `github_updates_app.vue`, simplified from the PoC's ~808 lines to roughly 350: - Replace the hand-rolled `setTimeout` polling loop (`fetchStatus()` on mount, `scheduleStatusRefresh()` re-arming a 5-second timer after every fetch) with `app/assets/javascripts/lib/utils/poll.js`. It fetches once on mount, then re-polls on the interval from the `Poll-Interval` response header, and stops for good once the project has fully cut over to GitLab, same as before. Pair it with the `visibilityjs` library, following poll.js's own documented usage pattern (`Visibility.change` calling `restart()`/`stop()`), so the panel pauses while the browser tab isn't visible and catches up immediately when it becomes visible again. That is why there is no separate polish issue for tab-visibility pausing; this port gets it for free by using poll.js the standard way. - Replace the bespoke "type the project path to confirm" stop-updates modal with `vue_shared/components/confirm_danger`, passing the project's full path as the `phrase` prop and the last-minute-GitHub-change warning as its confirmation message. It already implements exactly this pattern (a danger button disabled until the typed phrase matches), so `stop_github_updates_modal.vue` isn't ported as a new component. - Replace the hand-rolled table markup with `GlTableLite`, and drop the custom `aria-live` announcement/dedupe logic that existed to announce state changes; `GlTableLite` and standard alert patterns handle this adequately. - Collapse the six-overall-state by seven-per-domain-state matrix on the UI side. Only two things actually change behavior based on state: the "keep this project updated from GitHub" toggle is enabled only when the overall state is `provider_canonical` or `cutover_failed`, and "Update now" is enabled only when every row's sync state is `current`. Everything else across the other states is different badge or help text, not different logic, so the component shouldn't branch beyond picking display text. It still renders the two rows described above, an overall status badge, and the toggle. Turning the toggle off doesn't call any API directly, it opens the `confirm_danger` stop flow; only after the user types the project's exact full path and confirms does the parent component call the stop endpoint. Port the two view partials: `_github_updates.html.haml` (the settings-page card containing the Vue mount point and its data attributes) and `_github_updates_notice.html.haml` (a project-wide banner, shown on every project page while the project is read-only, with a link to view the repository on GitHub and, for admins, a link to this settings panel). Simplify the notice to one static alert, following the existing pattern in `app/views/projects/_importing_alert.haml`, instead of branching over five authority-state variants; drop the frontend's matching reload-on-change logic (`window.location.reload()` when a read-only transition is detected), since a static banner has nothing state-specific to refresh mid-poll. Port the one-line addition to `app/views/layouts/project.html.haml` that renders the notice partial, and the two-line additions to `app/assets/javascripts/pages/projects/settings/repository/show/index.js` and its EE counterpart that mount the new Vue app alongside the existing repository-settings mounts. Port the specs, shrunk to match the simplification above (the PoC's `github_updates_app_spec.js` is about 818 lines): - `spec/frontend/projects/settings/repository/github_updates/github_updates_app_spec.js`. Cover, at minimum: the toggle-enablement rule (enabled only in `provider_canonical`/`cutover_failed`), the "Update now" enablement rule (enabled only when every row is `current`), the stop confirmation flow through `confirm_danger` (the stop endpoint isn't called until the typed phrase matches the project's full path), and polling start/stop behavior around cutover. Since polling now runs through `~/lib/utils/poll`, this likely means asserting the component configures `Poll` correctly (resource, method, stopping on full cutover) rather than re-testing `Poll`'s own internals. - `spec/frontend/projects/settings/repository/github_updates/index_spec.js`. - `spec/requests/projects/continuity/github_updates_spec.rb`, covering the three remaining actions. - The two view specs under `spec/views/projects/`: `_github_updates_notice.html.haml_spec.rb` (now asserting one static alert instead of five variants) and `mirrors/_github_updates.html.haml_spec.rb`. - The EE frontend spec that confirms the new mount call happens. Do not port `stop_github_updates_modal_spec.js`; that component isn't ported, and `confirm_danger` already has its own specs. ## PoC files to read - `app/controllers/projects/continuity/github_updates_controller.rb` (ignore the `reconnect` action and its private helpers, they aren't ported) - `app/helpers/continuity/projects_helper.rb` - `app/helpers/projects_helper.rb` (one-line `include` change) - `config/routes/project.rb` (the `github_updates` resource; ignore the `reconnect` line) - `app/assets/javascripts/projects/settings/repository/github_updates/{constants,index,status_utils}.js` - `app/assets/javascripts/projects/settings/repository/github_updates/github_updates_app.vue` - `app/assets/javascripts/projects/settings/repository/github_updates/stop_github_updates_modal.vue` (read for its confirmation copy and warning text to carry into `confirm_danger`'s message; the component itself isn't ported) - `app/assets/javascripts/pages/projects/settings/repository/show/index.js` and `ee/app/assets/javascripts/pages/projects/settings/repository/show/index.js` - `app/views/projects/mirrors/_github_updates.html.haml`, `app/views/projects/_github_updates_notice.html.haml`, `app/views/layouts/project.html.haml` - Specs: `spec/frontend/projects/settings/repository/github_updates/{github_updates_app_spec,index_spec}.js`, `spec/requests/projects/continuity/github_updates_spec.rb`, `spec/views/projects/{_github_updates_notice.html.haml_spec.rb,mirrors/_github_updates.html.haml_spec.rb}`, `ee/spec/frontend/pages/projects/settings/repository/show/index_spec.js` Not PoC files, existing CE code being reused, worth reading for the pattern: - `app/assets/javascripts/lib/utils/poll.js` - `app/assets/javascripts/vue_shared/components/confirm_danger/` (`confirm_danger.vue`, `confirm_danger_modal.vue`, `constants.js`) - `app/views/projects/_importing_alert.haml` ## Acceptance criteria - The panel renders the correct combination of overall state and per-domain sync state for all six authority states and seven sync states; a reviewer confirms each rendered combination corresponds to a state the backend can actually be in. - The "keep this project updated from GitHub" toggle is enabled only when the overall state is `provider_canonical` or `cutover_failed`, and disabled for every other state. - "Update now" is enabled only when every row's sync state is `current`, and shows the right error when the project isn't in an updatable state. - "Stop updates" goes through `confirm_danger` requiring the project's exact full path; the stop endpoint isn't called until the typed phrase matches and the user confirms. - Polling starts when the page loads, keeps running on the interval from the `Poll-Interval` response header, and stops for good once the project has fully cut over to GitLab, matching the PoC's existing behavior. - The read-only banner appears on every project page while the project is read-only, and disappears once it isn't. - All ported specs pass. ## Out of scope - The "Check connection now" and "Manage GitHub App access" additions to this panel. Both come later, in a separate https://gitlab.com/gitlab-org/gitlab/-/work_items/628595 issue, on top of this port. - There is no separate polish issue for pausing polling on a hidden tab: using `~/lib/utils/poll` here, paired with `visibilityjs` the way poll.js's own docs describe, gets that behavior for free. - Any backend service this controller calls (request-update, stop); those are ported in other LAND issues, this issue only ports the controller, helper, and frontend that call them. `ReconnectService` isn't ported at all. ## Notes for the reviewer - Check the panel against the real backend states, not just against this description: confirm every authority/sync-state combination the Vue app can render actually corresponds to a state `Import::Sync::Repository` and `Import::Sync::RepositoryState` can really be in, and that there's no combination the UI shows that the backend can never produce (or vice versa). - `bootstrap_canceled` deliberately doesn't appear in the frontend's state map, the panel is hidden entirely for that state at the helper level (`show_github_updates_settings?`). Confirm that's still true after the port, not an oversight. - `reconnect` is gone on purpose, not an oversight: the 30-minute background lifecycle repair check already restores access automatically, so there's no user-facing reconnect action left to port. Don't add a reconnect button back in during review; "Check connection now" is a deliberately separate, later https://gitlab.com/gitlab-org/gitlab/-/work_items/628595 addition. - Confirm the simplified toggle and "Update now" enablement rules match the PoC's `toggleDisabled`/`updateButtonDisabled` computeds exactly, even though the rest of the state matrix is now just display text rather than branching logic. --- **OAuth-path note:** This panel renders from `project.import_sync_repository`, which will include OAuth-connected repositories once #630400 lands. The separately-scoped "Check connection now" / "Manage GitHub App access" additions (deferred to a later issue per this issue's own "Out of scope" section) remain App-specific and out of scope here, same as originally written — no change needed to this issue's core panel. --- **Added after the review of !262611 (stop / cutover):** two cases where a stop completes without the final GitHub pass, and what the panel shows afterwards. - **Warn when a stop skipped the final pass.** `FinishStopService` completes a stop without the final pass in two cases: GitHub returns 404 for the repository (deleted, or a private repository the token can no longer see, for example after the user left the organization), and the import failed or was canceled. Today the only record is a log line. No new column is needed: a normal stop only completes when no domain is lagging, both skip paths leave lagging domains, and nothing can bump a domain after `gitlab_canonical`. So `status` returns whether the stop completed without a full final pass (`gitlab_canonical` with a lagging domain), and the panel shows one generic warning that recent GitHub changes may be missing. Discussed in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/262611#note_4031804143. - **Ignore the domain states once the project is `gitlab_canonical`.** After a stop that skipped the final pass, the domain states can stay `degraded`/`pending` forever (`desired_generation` ahead of `synced_generation`). The panel must not present that as a failed or pending GitHub update on a project that no longer syncs: once the overall state is `gitlab_canonical`, the rows show that updates have stopped instead of the per-domain sync state. Acceptance criteria for these: - [ ] After a stop that completed without the final pass, `status` says so and the panel shows a warning that recent GitHub changes may be missing; a normal stop shows none. - [ ] With the overall state `gitlab_canonical`, the panel shows no per-domain sync state (no degraded or pending badge), whatever the stored domain states are. **Placement: its own section, not inside "Mirroring repositories".** The panel moves to its own "GitHub updates" section on Settings > Repository instead of the PoC's card under mirroring: repository mirroring is blocked for these projects, the card had to explain that it was not a mirror, and the read-only banner's admin link can open the section directly. Design input welcome on the MR.