feat(artifact): unblock v4+ on self-hosted GHES when ACTIONS_RESULTS_URL is set

[camjay]

Closes #2439
Related to #2123 (more general vendor-aware approach for non-GitHub servers; this PR addresses the narrower GHES-3.13+ case via existing runtime signals)

isGhes() in packages/artifact/src/internal/shared/config.ts currently throws GHESNotSupportedError on any GHES, regardless of release. GHES 3.13 added the artifact-storage-v2 backend that v4+ requires, but the gate is hostname-only and ignores the release. ACTIONS_RESULTS_URL is the runtime signal for v2 availability; the same package's getResultsServiceUrl() already requires it. This change makes isGhes() return false when the hostname looks like GHES and ACTIONS_RESULTS_URL is set.

Behaviour matrix:

• github.com, *.ghe.com, *.localhost: hostname check still returns false. No change.
• GHES <3.13 (no v2 backend, ACTIONS_RESULTS_URL unset): isGhes() returns true, throws as before. No change.
• GHES 3.13+ (v2 backend present, ACTIONS_RESULTS_URL set): isGhes() returns false, upload/download/list proceed.

Tests in packages/artifact/__tests__/config.test.ts cover both new branches. Also added a beforeEach cleanup of GITHUB_SERVER_URL and ACTIONS_RESULTS_URL inside the isGhes describe block; the previous setup relied on jest.resetModules() alone and could leak ACTIONS_RESULTS_URL from sibling tests. The previously-misleadingly-titled "should return false ... is specific to an enterprise" test (which expected true) is renamed to match its actual assertion.

Verified on a GHES 3.19.5 instance where the v2 backend is operational but v4+ artifact actions were blocked solely by the hostname gate.

Relationship to #2123: that PR takes a more general approach with an ACTIONS_VENDOR env var as an explicit opt-in, supporting non-GitHub vendor servers (Gitea, Forgejo, etc.) in addition to GHES. This PR is narrower: it consults an existing runtime signal (ACTIONS_RESULTS_URL) that GHES 3.13+ runners already emit, so no operator action is required and no new env-var contract is introduced. The two approaches are complementary; if both land, the check here would short-circuit before vendor detection on v2-supporting GHES.

[camjay]

Hey @actions/artifacts-actions, @danwkennedy, @jasongin: bumping this on the back of the artifact README's own note that v4 is "not currently supported on GHES yet."

GHES 3.13+ ships the v2 artifact backend; on those releases the runner already exports ACTIONS_RESULTS_URL. The current isGhes() check in packages/artifact/src/internal/shared/config.ts is purely hostname-based, so it short-circuits before that signal is consulted and v4 stays blocked even where the backend is fully present. This PR is a one-line gate change plus tests: keep the hostname heuristic, but skip blocking when ACTIONS_RESULTS_URL is set, which is the same signal the upload/download flow uses downstream.

Related: #2439 (issue) and the older #2123 (different approach to the same problem, open since early 2026).

Happy to adjust scope/tests/style. Just looking for a triage decision so we know whether to keep iterating here or pursue an ADR per CONTRIBUTING.md.

[philip-gai]

@camjay Thanks for the PR! The v2 (Results) backend that @actions/artifact v4+ requires isn't available on GHES, so this should stay blocked there.

GHES 3.13 added the artifact-storage-v2 backend that v4+ requires

This isn't the case, it's still unsupported on GHES (the README calls this out too). GHES runners also don't set ACTIONS_RESULTS_URL, so the check here wouldn't fire on a real GHES instance anyway, and if it did get set for some other reason, it'd swap the clear GHESNotSupportedError for confusing downstream failures.

Let me know if I'm misunderstanding something! 😄