GHE.com source: createMigrationSource registers https://github.com instead of the tenant URL (v1.32.0)

[nx-ahmed-bessaidi]

Version

gh-gei v1.32.0 (confirmed current — CLI's own check against LATEST-VERSION.txt passes)

Environment

• Source: GHE.com tenant neoxam.ghe.com (EMU)
• Target: github.com (Enterprise Cloud)
• Using --github-source-api-url, per the v1.32.0 release note adding GHE.com as a source

Command

gh gei migrate-repo \
  --github-source-org "NX-RD" --source-repo "test-workflow" \
  --github-target-org "NX-RD" --target-repo "test-workflow" \
  --github-source-api-url "https://api.neoxam.ghe.com" \
  --use-github-storage --verbose

---

Issue 1 — migration source URL hardcoded to github.com

The CLI resolves the source API URL correctly at startup:

[2026-08-24 16:50:38] [INFO] GITHUB SOURCE API URL: https://api.neoxam.ghe.com

but createMigrationSource sends https://github.com as the source URL:

[2026-08-24 16:50:39] [DEBUG] HTTP POST: https://api.github.com/graphql
[2026-08-24 16:50:39] [DEBUG] HTTP BODY: {"query":"mutation createMigrationSource($name: String!, $url: String!, $ownerId: ID!, $type: MigrationSourceType!) { createMigrationSource(input: {name: $name, url: $url, ownerId: $ownerId, type: $type}) { migrationSource { id, name, url, type } } }","variables":{"name":"GHEC Source","url":"https://github.com","ownerId":"O_kgDOElw9Qw","type":"GITHUB_ARCHIVE"},"operationName":"createMigrationSource"}
[2026-08-24 16:50:39] [DEBUG] RESPONSE (OK): {"data":{"createMigrationSource":{"migrationSource":{"id":"MS_kgDaACQ0N2VlYWU1Zi05MDdmLTRhZTQtOTUyMi1kMmQ2OGFkMjQwMDg","name":"GHEC Source","url":"https://github.com","type":"GITHUB_ARCHIVE"}}}}

Reproduced on every run across two orgs and two repos. Expected: the source URL should reflect --github-source-api-url / GH_SOURCE_API_URL.

Issue 2 — GHES Management Console warning on a GHE.com source

[2026-08-24 16:50:38] [WARNING] Providing the --use-github-storage flag will supersede any credentials you have configured in your GitHub Enterprise Server (GHES) Management Console.

GHE.com has no Management Console, so this warning is inapplicable on the new source path.

---

Context — server-side git export failure (raised separately with Support)

I don't believe this is a CLI defect, but flagging it in case the GHE.com source path is known to be incomplete beyond the two items above.

Every git archive job fails 12–14s after entering exporting, with no reason exposed by GET /orgs/{org}/migrations/{id}. Six consecutive jobs in this run:

[2026-08-24 16:50:39] [INFO] Archive generation of git data started with id: 105342
[2026-08-24 16:50:40] [INFO] Waiting for archive with id 105342 generation to finish. Current status: exporting
[2026-08-24 16:51:01] [INFO] Waiting for archive with id 105342 generation to finish. Current status: failed

git job	created	failed	elapsed
105342	15:50:39	15:50:53	14s
105352	15:51:05	15:51:17	12s
105362	15:51:34	15:51:48	14s
105372	15:52:07	15:52:21	14s
105382	15:52:45	15:52:58	13s
105392	15:53:26	15:53:40	14s

The request bodies are minimal and identical each time:

[2026-08-24 16:50:39] [DEBUG] HTTP BODY: {"repositories":["test-workflow"],"exclude_metadata":true}

Metadata generation succeeds for the same repo and invocation — job 98182 (guid 29da1960-9bad-11f1-8ad5-4965a467bf10, 19 Aug) reached exported. Only the git archive fails.

Ruled out by controlled retests across 19 and 24 Aug:

• size — fails on an 11–13 KB repo ("size": 13)
• releases — none present; the failing job is the git archive
• wiki — "has_wiki": false on all runs above
• --use-github-storage — reproduces without it; generation fails before upload, and the same invocation's metadata job succeeds
• repository contents/history — two unrelated repos
• organization — fails in both NX-DSI and NX-RD
• CLI version — v1.32.0

Earlier failing git jobs: 97707, 98177, 98227 (NX-DSI/playbooks-gitops, 104 KB); 98377, 98387, 98397, 98407 (NX-RD/test-workflow).

migration.log

[brianaj]

@nx-ahmed-bessaidi thanks for opening this issue. I will address the cli related issues 1 & 2 which are not functionally blocking bugs. The actual export failure should be handled related the support path you are already aware of for our on-call team to take a look into.