Skip to content

push_repo_memory.cjs script has hardocoded github.com reference #16150

@jaroslawgajewski

Description

@jaroslawgajewski

Problem

fix for the git URL construction in the push_repo_memory.cjs script . Currently, some environments (specifically GitHub Enterprise) fail authentication because:

  1. The git URL is constructed using the token as the username only, whereas GitHub requires the x-access-token: prefix.
  2. The git host is hardcoded to github.com in several places, which fails for Enterprise instances (e.g., mycompany.ghe.com).

Include your agent's analysis and findings

My analysis shows that the push_repo_memory.cjs script (and potentially the repo_memory.go compiler logic) constructs git URLs in the format:
https://<token>@github.com/owner/repo.git or https://x-access-token:<token>@github.com/owner/repo.git

There are two major issues for GitHub Enterprise (GHE) users:

  1. Missing user prefix: GitHub's authentication mechanism for tokens requires the format https://x-access-token:<token>@host/.... Without the x-access-token: prefix, the server interprets the token as a username and expects a password, leading to Authentication failed.
  2. Hardcoded host: Several built-in scripts and compiler templates hardcode github.com as the git host. For GHE instances, this means the git commands attempt to connect to the wrong server, or fail because the token provided is not valid for github.com.

Found affected locations:

  • actions/setup/js/push_repo_memory.cjs: Hardcoded github.com in repoUrl construction.
  • pkg/workflow/repo_memory.go: Hardcoded github.com in generated git push/pull commands.
  • pkg/workflow/yaml_generation.go: The "Configure Git credentials" step exists but may not fully catch hardcoded URLs in external scripts if the insteadOf rule is too specific.

Explain the use case and expected behavior

Use Case:
Running gh-aw workflows in a GitHub Enterprise environment that utilize repo-memory or other features requiring git pushes back to the repository.

Expected Behavior:
The workflows should dynamically use the current GitHub host (from github.server_url) and properly formatted authentication credentials (x-access-token:<token>).

Actual Behavior:
Git operations fail on GHE with Authentication failed or Could not resolve host: github.com.

Provide examples if applicable and proposal how to fix it

Example of failure on GHE:

// push_repo_memory.cjs
const repoUrl = `https://x-access-token:${ghToken}@github.com/${targetRepo}.git`;
// On GHE, this should be:
// const repoUrl = `https://x-access-token:${ghToken}@${serverHost}/${targetRepo}.git`;

Proposed Fix:

The fix involves updating the "Configure Git credentials" step in the compiler to add robust insteadOf rewrites that catch both malformed URLs and hardcoded github.com hosts on Enterprise instances.

Updated "Configure Git credentials" implementation:

# In pkg/workflow/yaml_generation.go
git config --global url."https://x-access-token:${GIT_TOKEN}@${SERVER_URL#https://}/".insteadOf "https://${GIT_TOKEN}@github.com/"
git config --global url."https://x-access-token:${GIT_TOKEN}@${SERVER_URL#https://}/".insteadOf "https://x-access-token:${GIT_TOKEN}@github.com/"
git config --global url."https://x-access-token:${GIT_TOKEN}@${SERVER_URL#https://}/".insteadOf "https://${GIT_TOKEN}@${SERVER_URL#https://}/"

This triple-layer rewrite ensures that:

  1. https://<token>@github.com/ -> https://x-access-token:<token>@GHE_HOST/
  2. https://x-access-token:<token>@github.com/ -> https://x-access-token:<token>@GHE_HOST/
  3. https://<token>@GHE_HOST/ -> https://x-access-token:<token>@GHE_HOST/

Additionally, built-in scripts should be updated to use GITHUB_SERVER_URL when available instead of hardcoding github.com.

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions