Skip to content

fix(artifacts-init): honor gh/glab git_protocol when picking push URL#1469

Open
0xDevNinja wants to merge 1 commit into
garrytan:mainfrom
0xDevNinja:fix/1348-honor-git-protocol
Open

fix(artifacts-init): honor gh/glab git_protocol when picking push URL#1469
0xDevNinja wants to merge 1 commit into
garrytan:mainfrom
0xDevNinja:fix/1348-honor-git-protocol

Conversation

@0xDevNinja

@0xDevNinja 0xDevNinja commented May 13, 2026

Copy link
Copy Markdown
Contributor

Summary

  • gstack-artifacts-init now honors gh config get git_protocol (and glab config get git_protocol for the gitlab branch) when deriving the push URL.
  • New --push-protocol auto|https|ssh flag lets users pin explicitly. auto is the default.
  • Empty / unreadable config falls back to SSH, so users who never set git_protocol see no change.
  • 7 new tests cover all four auto paths (github/gitlab × https/ssh), both explicit overrides, the unset-fallback, and invalid-value rejection.

Fixes #1348.

Why

bin/gstack-artifacts-init:184 (post v1.27.0.0 rename from gstack-brain-init) unconditionally converts the canonical HTTPS URL to its SSH form for git push origin:

PUSH_URL=$("$URL_BIN" --to ssh "$CANONICAL_HTTPS" 2>/dev/null || echo "$CANONICAL_HTTPS")

Users whose gh auth login defaulted to HTTPS (the gh default since 2.x) don't have an SSH key on the remote. The post-create git ls-remote $PUSH_URL step then hangs on an SSH prompt, exits, and the script bails with Remote not reachable via SSH:. Recovery required rerunning with --remote <https url>, which only works if the user knows the workaround.

Same hazard on the gitlab branch — glab config get git_protocol is parallel.

Fix

Three-step resolution for the push URL:

  1. --push-protocol https|ssh flag wins (lets the user pin regardless of CLI state — useful in CI / scripted setups).
  2. auto (default) queries the per-host CLI config:
    • githubgh config get git_protocol
    • gitlabglab config get git_protocol
  3. Empty / unreadable / unknown value → SSH (historical default; no regression for users who never set git_protocol).

The ls-remote failure message also now points HTTPS users at the override flag, so the next attempt is one rerun away rather than a workaround hunt.

Tests

Extended the existing makeFakeGh / makeFakeGlab shims with an optional gitProtocol arg so they respond to gh config get git_protocol (and glab config get git_protocol). New describe('gstack-artifacts-init push protocol (issue #1348)') block, 7 cases:

  • gh git_protocol=https → origin URL is HTTPS.
  • gh git_protocol=ssh → origin URL is SSH (existing behavior preserved).
  • gh git_protocol unset → origin URL is SSH (legacy default preserved).
  • --push-protocol https overrides gh git_protocol=ssh.
  • --push-protocol ssh overrides gh git_protocol=https.
  • --push-protocol bogus exits 1 with Invalid --push-protocol.
  • gitlab branch: glab git_protocol=https → origin URL is HTTPS.
bun test test/gstack-artifacts-init.test.ts
# 23 pass, 0 fail (16 existing + 7 new)

Notes

  • No CHANGELOG / VERSION bump in the diff (maintainer-owned at squash-merge per repo convention).
  • --push-protocol deliberately covers only the local push URL; ~/.gstack-artifacts-remote.txt continues to store the canonical HTTPS form (codex Finding Add Claude Code marketplace configuration #10).
  • Does not touch gstack-artifacts-url --to ssh — that helper is still the right derivation primitive; only the auto policy in artifacts-init changes.

View in Codesmith
Need help on this PR? Tag @codesmith with what you need.

  • Let Codesmith autofix CI failures and bot reviews
`gstack-artifacts-init` always converted the canonical HTTPS URL to its
SSH form for `git push origin`. Users on `gh config set git_protocol
https` (the `gh auth login` default) lack an SSH key on the remote, so
the post-create `git ls-remote $PUSH_URL` verification fails with a
cryptic SSH prompt and the script exits without finishing setup. Same
hazard on the gitlab branch.

Pre-fix the only recovery was rerunning with `--remote <https url>`,
which bypassed the canonicalization step entirely and required the user
to know the workaround.

Resolution order for the push URL:
  1. `--push-protocol https|ssh` flag wins.
  2. `auto` (default) reads `gh config get git_protocol` (github branch)
     or `glab config get git_protocol` (gitlab branch).
  3. Empty / unreadable config falls back to SSH — the historical
     default, kept so users who never set `git_protocol` see no change.

Error message after a failed `ls-remote` also points HTTPS users at the
override flag, so the next attempt is one rerun away.

Fixes garrytan#1348
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant