[GHES] Frontend: Import Repo Creation & Cross-Cluster Resource Management

[airsoc]

🏷️ Discussion Type

Question

Body

Summary

This feature request proposes two complementary frontend enhancements for GitHub Enterprise Server (GHES):

1. Full Import Repository Creation UI — A complete, end-to-end frontend workflow for importing repositories from external sources (github.com, GitLab, Bitbucket, or bare Git URLs) with support for migrating issues, PRs, wikis, LFS objects, and organization membership.

2. Cross-Cluster Unified Resource Management UI — A centralized management interface allowing GHES site administrators to discover, monitor, and act on resources (repositories, organizations, users, actions runners) across multiple GHES cluster nodes or geo-replicas from a single pane of glass.

---

Motivation & Background

Problem 1 — Import Repository Creation

Currently, GHES administrators and users who want to import repositories must rely on the ghe-migrator CLI tool or the Migrations REST API. There is no integrated frontend UI within the GHES instance itself that guides users through:

• Selecting an import source (github.com, GitLab, Bitbucket, bare Git)
• Authenticating against the source
• Choosing which data to migrate (code, issues, PRs, wikis, LFS)
• Mapping source users/teams to GHES identities
• Monitoring import progress with live status and error reporting

This gap forces technical users to context-switch to CLI tools and leaves non-technical org owners without a self-serve migration path.

Problem 2 — Cross-Cluster Resource Management

Large enterprises running GHES in a clustered or geo-replicated topology have no unified frontend to manage resources that span multiple nodes. Admins must SSH into individual primaries or use per-node Management Console URLs. There is no single view for:

• Cluster health and node status
• Repository distribution across nodes
• Actions runner pool utilization per cluster
• Draining or rebalancing workloads between nodes
• Audit log aggregation across the cluster

---

Proposed Solution

Feature 1: Import Repository Creation Wizard

A multi-step wizard accessible from /{org}/repositories/import and the site admin panel.

Step 1 — Source Selection

• Support github.com, GitLab, Bitbucket Cloud/Server, Azure DevOps, and bare Git URLs
• OAuth or PAT-based authentication per source provider

Step 2 — Repository & Data Selection

• List available repositories from the authenticated source
• Checkboxes for: Issues, Pull Requests, Wiki, Releases, LFS objects, Projects
• Namespace conflict detection with inline resolution prompts

Step 3 — Identity Mapping

• Auto-match source users to GHES users by email/username
• Manual override UI for unmapped contributors

Step 4 — Import Options

• Target organization and visibility (private/internal/public)
• Preserve original timestamps toggle
• Webhook forwarding configuration

Step 5 — Progress & Results

• Live streaming progress view (SSE or polling)
• Per-object-type status (repos, issues, PRs)
• Downloadable import report (JSON/CSV)
• Error log with actionable remediation hints

---

Feature 2: Cross-Cluster Unified Resource Management Dashboard

A new section in the site admin panel at /_admin/cluster.

Cluster Overview Panel

• Node topology map (primary, replicas, cache nodes)
• Real-time health indicators: CPU, memory, disk, replication lag
• One-click failover initiation with pre-flight checks

Resource Explorer (cross-cluster search)

• Search repositories, organizations, users across all nodes
• Filter by node, tier, or replication status
• Bulk actions: transfer, archive, delete with confirmation flow

Actions Runner Management

• Aggregated runner pool view grouped by runner group and node
• Drain/force-offline individual runners across nodes
• Runner registration token generation per cluster zone

Audit & Compliance

• Unified audit log stream from all cluster nodes
• Exportable to SIEM-compatible formats (CEF, JSON)
• Retention policy management per node or globally

---

User Stories

• As an org owner, I want to import my GitLab repositories into GHES through a guided UI without needing CLI access, so that I can migrate my team independently.
• As a site admin, I want to see all my cluster nodes' health on one dashboard, so that I can respond to replication lag before it causes outages.
• As a platform engineer, I want to search for a specific repository across all cluster nodes from one interface, so that I don't have to SSH into multiple primaries.
• As a compliance officer, I want to export a unified audit log from all cluster nodes in CEF format, so that I can feed it directly into our SIEM.

---

Acceptance Criteria

Import Repository Creation

• Wizard is accessible from org-level and site admin panel
• Supports at minimum: github.com, GitLab, Bitbucket, bare Git URL
• Live progress view updates without full page reload
• Namespace conflicts surface inline with resolution options
• Import report downloadable upon completion or failure
• All import actions are reflected in the audit log

Cross-Cluster Resource Management

• Cluster topology view displays all registered nodes
• Replication lag surfaced per node with alert thresholds
• Cross-node resource search returns results within 5s for standard cluster sizes
• Bulk actions require explicit confirmation and are logged
• Audit log export supports JSON and CEF formats
• Dashboard is accessible to site admins only (RBAC enforced)

---

Out of Scope

• Migration of GitHub Actions workflow run history
• Real-time collaborative editing of cluster config via UI (config-as-code remains the source of truth)

---

Additional Context

• Related to community discussions on https://github.com/orgs/community/discussions
• Comparable to the import wizard available on github.com (github.com/new/import)
• Cross-cluster management is a common request in enterprise support tickets and community threads

We welcome feedback on priority, scope, and implementation approach. If there is an existing internal tracking item for either feature, please link it here.

[Crackle2K]

Both of these are well-scoped and address real pain points that come up frequently in enterprise support threads. The import wizard especially fills an obvious gap since github.com has had one for years and GHES users have been working around it with ghe-migrator forever. The cross-cluster dashboard is a bigger lift but the use cases (replication lag visibility, unified audit log, cross-node search) are exactly what large orgs ask for. One thing worth flagging for the import wizard: SSE-based live progress is going to be tricky if your GHES is behind a proxy or load balancer that buffers responses, so it may be worth designing the progress view to fall back gracefully to polling. For the cluster dashboard, the 5-second cross-node search SLA is reasonable but worth stress-testing against clusters with heavy repository counts before committing to it in the acceptance criteria.

[airsoc]

@Crackle2K Thanks for the detailed feedback — both points are well-taken.

On the SSE fallback: completely agree. A proxy or load balancer that buffers Transfer-Encoding: chunked responses will silently break SSE, which is a realistic deployment scenario for most enterprises. The progress view should implement a tiered strategy: attempt SSE first, detect a stalled connection after a short timeout (e.g. 10–15s with no event received), and transparently fall back to polling at a configurable interval (default ~3s). The UI state machine should be identical either way so users never see a seam. Worth documenting the required proxy headers (X-Accel-Buffering: no for nginx, DisableChunkedTransferEncoding for ARR, etc.) in the GHES admin docs alongside this feature.

On the 5s cross-node search SLA: you're right that this needs qualification. The criterion as written is underspecified — "standard cluster sizes" is doing a lot of work. A more defensible formulation might be something like:

Cross-node resource search returns results within 5s for clusters of up to 8 nodes with up to 50,000 repositories per node, under typical read load.

That gives the team a concrete baseline to stress-test against before GA and sets honest expectations for customers with unusually large repository counts. It also implies the dashboard should surface a warning when result sets are truncated due to timeout, rather than silently returning partial data.

Both of these could become sub-items under their respective acceptance criteria if the team wants to track them explicitly. Happy to update the original post if that would be useful.

[tanvishinde017]

Hi @aivsec,

This is a very comprehensive proposal with clear motivation, user stories, acceptance criteria, and scope boundaries.

A guided repository import experience inside GHES would certainly lower the barrier for migrations, especially for organizations that prefer self-service workflows over CLI tools. The identity mapping and progress reporting ideas are particularly valuable.

The unified cross-cluster dashboard would also be useful for large enterprise deployments, though I imagine some capabilities (such as failover operations and cross-node actions) would require careful consideration around permissions, scalability, and operational safety.

A couple of thoughts that might strengthen the proposal further:

• Consider whether some cluster-management capabilities should be read-only by default, with destructive actions gated behind additional confirmation.
• It may be helpful to prioritize the dashboard into phases (health visibility first, then resource management, then operational actions).
• Since github.com already provides an import experience, reusing similar UX patterns in GHES could help reduce the learning curve.

Overall, this feels like two strong feature requests that address real enterprise pain points. Thanks for taking the time to document them so thoroughly.

[airsoc]

@tanvishinde017 Thanks for the thoughtful response — all three suggestions are worth building on.

On read-only defaults and confirmation gates: Fully agree, and this should probably be explicit in the acceptance criteria rather than left to implementation discretion. A reasonable permission model might be:

• Read (cluster health, topology, audit log view): any site admin
• Write (bulk archive, transfer, runner drain): site admin + explicit org owner consent for resources they own
• Destructive (failover initiation, force-delete): site admin with a required two-step confirmation dialog that surfaces a plain-language impact summary (affected repos, active jobs, replication state) before proceeding

The last category in particular should also generate an audit log entry before the action executes, not just after, so there's a record even if the operation fails mid-flight.

On phasing the dashboard: This is probably the most practical way to ship incrementally without blocking on the full scope. A rough phase breakdown might look like:

• Phase 1 — Observability: Node topology map, health indicators, replication lag, unified audit log view (read-only throughout)
• Phase 2 — Resource Management: Cross-node search, repository/org/user explorer, bulk read operations
• Phase 3 — Operational Actions: Runner drain, failover initiation, bulk destructive actions with confirmation gates

This also de-risks the 5s search SLA concern raised earlier — Phase 1 can ship without it, giving the team time to benchmark against real cluster sizes before committing to it in Phase 2.

On reusing github.com UX patterns: Strong point. The github.com/new/import wizard already has established UX conventions (source auth, progress stepper, conflict resolution inline) that GHES users will recognize if they've ever managed a migration on github.com. Diverging from those patterns without a clear reason adds unnecessary cognitive overhead. Where GHES-specific concerns require different flows (e.g. identity mapping against LDAP/SAML, or LFS storage routing), those can be additive rather than replacing the familiar patterns.

Would you support adding phased delivery as a formal section to the original proposal? It would make it easier for the team to scope an initial milestone without having to take on both features in full.