[BUG] apm marketplace build fails for GitHub Enterprise Server repositories

[kkadete]

Describe the bug

Running apm marketplace build against a marketplace whose packages are hosted on a GitHub Enterprise Server (GHES) instance always fails with a Git authentication error, even when GITHUB_HOST and a valid GHE token are set in the environment.

The error message reveals that APM is contacting github.com instead of the configured GHE host, so authentication always fails regardless of the credentials provided.

To Reproduce

Steps to reproduce the behavior:

1. Author a marketplace.yml with packages sourced from a GHES instance (e.g. corp.ghe.com)
2. Set GITHUB_HOST=corp.ghe.com in the environment
3. Set GITHUB_TOKEN to a valid personal access token for that GHE instance
4. Run apm marketplace build --dry-run --verbose
5. See error:

GitLsRemoteError: Git authentication failed during ls-remote for 'org/repo'.
  Remote: https://github.com/org/repo.git
  Hint: Check that GITHUB_TOKEN is set and has read access to the repository.

Note the remote URL in the error — it points to github.com instead of the GHE host, confirming GITHUB_HOST is not being respected.

Expected behavior

Setting GITHUB_HOST=corp.ghe.com should cause apm marketplace build to resolve package refs against that host, consistent with how apm install already supports the host/owner/repo syntax for GHE repos.

Environment:

• OS: Windows (Cygwin)
• APM Version: 0.10.0
• VSCode Version: latest

Logs

$ GITHUB_HOST=corp.ghe.com apm marketplace build --dry-run --verbose
...
GitLsRemoteError: Git authentication failed during ls-remote for 'org/repo'.
  Remote: https://github.com/org/repo.git
  Hint: Check that GITHUB_TOKEN is set and has 'repo' scope...

Additional context

This affects the marketplace-authoring experimental feature. The apm install command supports GHE via host/owner/repo notation, so there is precedent for GHE support in APM. The marketplace build command appears to not yet have equivalent support.

[github-actions]

Triage decision

accept

Proposed labels

theme/portability
area/marketplace
area/enterprise
type/bug
status/accepted
priority/high

Milestone

0.10.1

Suggested next action

Wire apm marketplace build's repository URL construction through the same GITHUB_HOST-aware host resolution that apm install already uses, then add a regression test with a stubbed GHE host.

Suggested issue comment

Thanks for the detailed report, @kkadete -- the reproduction steps, error log, and version info made this very easy to confirm.

This is a genuine bug. `apm install` already supports GitHub Enterprise Server via the `host/owner/repo` notation and `GITHUB_HOST` environment variable, but that host-resolution logic was not wired into `apm marketplace build`. As a result, `marketplace build` always constructs remote URLs against `github.com`, ignoring any configured enterprise host.

The fix is to thread `GITHUB_HOST` through the same auth and host-resolution path that `apm install` uses. This is a well-understood pattern in the codebase -- no design work is needed before the fix can land.

We are tracking this for the `0.10.1` patch release with `priority/high`.

If you would like to contribute the fix, the entry points to look at are the host resolution utilities used by `apm install` (search for `HostInfo` / `AuthResolver` in `src/apm_cli/`) and the `marketplace build` command path. The [contribution guide](https://github.com/microsoft/apm/blob/main/CONTRIBUTING.md) has everything you need to get started. Feel free to comment here if you have questions while working on it.

Per-lens notes (collapsed)

DevX UX Expert -- User-Need Reviewer

The request maps directly to a real CLI surface: apm marketplace build is a shipped (experimental) command and GHE environments are a supported deployment target. The consistency gap is clear: apm install honors GITHUB_HOST via host/owner/repo notation, but marketplace build silently ignores it and hard-codes github.com in the constructed remote URL. The error message does surface the wrong URL, which aids diagnosis, but the root cause is a missing host-resolution step. No UX redesign is needed -- the fix is to apply the existing pattern consistently. High confidence this is a valid, actionable bug.

Supply Chain Security Expert -- Risk-Surface Reviewer

Auth and host resolution are in scope. The security model is sound: the user supplies a valid token for the right host; the bug is that the wrong URL is being constructed, so the token is presented to the wrong endpoint and rejected. Fixing this means routing marketplace build through the same AuthResolver/HostInfo path already validated for apm install. No new attack surface is introduced. The relevant areas are area/marketplace and area/enterprise. theme/portability is the correct mega-theme -- this is a portability/consistency bug, not a security vulnerability.

OSS Growth Hacker -- Contributor-Tone Reviewer

kkadete has author_association: NONE, making this a first-time or low-interaction contributor. The report is technically sharp -- they identified the wrong remote URL in the error log and cross-referenced the existing apm install GHE precedent. Reply tone should be warm and validating without being instructional. Explicitly confirm the bug, name the affected milestone, and offer a concrete on-ramp if they want to contribute the fix (pointer to HostInfo/AuthResolver + CONTRIBUTING.md). Avoid generic "thanks for the issue" phrasing -- make it clear their research was noticed.

Python Architect -- Architecture Reviewer

Not activated -- The bug is a contained fix extending existing GITHUB_HOST-aware host resolution from apm install to apm marketplace build; no new interface, data model, or cross-cutting design decision is required before code can land.

Doc Writer -- Documentation Reviewer

Not activated -- This is a bug fix restoring correct behavior for an already-documented configuration pattern (GITHUB_HOST); no new user-facing documentation pages are needed, though the implementing PR may optionally add a GHE note to the marketplace authoring guide.

APM CEO -- Triage Arbiter

Clear accept with priority/high. This is a blocking bug for enterprise GHE users who depend on apm marketplace build, and the fix follows established precedent in apm install -- no design phase needed. theme/portability is correct: the issue is about consistent GHE support across commands, not a security model gap. Milestone 0.10.1 (the open patch immediately after the reporter's version) is the right target. The reply should warmly validate the sharp report and give the author a clear contributor on-ramp.

{
  "decision": "accept",
  "decision_detail": "",
  "theme": "theme/portability",
  "areas": ["area/marketplace", "area/enterprise"],
  "type": "type/bug",
  "status": "status/accepted",
  "priority": "priority/high",
  "preserved_labels": [],
  "milestone": "0.10.1",
  "next_action": "Wire apm marketplace build's repository URL construction through the same GITHUB_HOST-aware host resolution that apm install already uses, then add a regression test with a stubbed GHE host.",
  "comment_markdown": "Thanks for the detailed report, @kkadete -- the reproduction steps, error log, and version info made this very easy to confirm.\n\nThis is a genuine bug. `apm install` already supports GitHub Enterprise Server via the `host/owner/repo` notation and `GITHUB_HOST` environment variable, but that host-resolution logic was not wired into `apm marketplace build`. As a result, `marketplace build` always constructs remote URLs against `github.com`, ignoring any configured enterprise host.\n\nThe fix is to thread `GITHUB_HOST` through the same auth and host-resolution path that `apm install` uses. This is a well-understood pattern in the codebase -- no design work is needed before the fix can land.\n\nWe are tracking this for the `0.10.1` patch release with `priority/high`.\n\nIf you would like to contribute the fix, the entry points to look at are the host resolution utilities used by `apm install` (search for `HostInfo` / `AuthResolver` in `src/apm_cli/`) and the `marketplace build` command path. The [contribution guide](https://github.com/microsoft/apm/blob/main/CONTRIBUTING.md) has everything you need to get started. Feel free to comment here if you have questions while working on it."
}

---

Triage status: agentic proposal pending human ratification.
Silence is approval. Maintainers can:

• Override any label or milestone above by editing it directly --
  human edits are authoritative and will not be reverted on
  subsequent runs.
• Re-trigger triage by applying the status/needs-triage label, or
  by removing status/triaged to enroll the issue in the next
  daily sweep.

Posted by the Triage Panel workflow. See .apm/skills/apm-triage-panel for the panel skill.

Generated by Triage Panel for issue #1008 · ● 839K · ◷