Route Checkpoints Through entire:// Mirrors
when i push things still go via SSH to github. i'd prefer pushes (of checkpoints as well as my other git operations) all use entire:// push-through mirrors. figure out from @.entire/settings.json why this isn't the case.
Found it — your settings force checkpoints onto GitHub, and the resolver can't produce entire:// URLs at all.
Bottom line: Your normal pushes already go through the mirror (origin is entire://aws-ap-southeast-2.entire.io/gh/entireio/cli). The SSH-to-GitHub traffic is the checkpoint machinery, caused by checkpoint_remote: {"provider": "github", ...} in .entire/settings.json:5-8 — and there is currently no way to configure a checkpoint remote that routes via entire://. It's a feature gap, not a settings mistake.
The exact chain:
- At pre-push,
resolvePushSettingscallsremote.PushURL(ctx, "origin")(cmd/entire/cli/strategy/checkpoint_remote.go:70). PushURLtries to derive the checkpoint URL from origin's protocol, butentire://is not a "derivable" transport — only SSH and HTTPS are (cmd/entire/cli/checkpoint/remote/util.go:284-286,util.go:288-302).- So it falls into
resolveProviderCheckpointURL(util.go:226), which maps providergithub→ hostgithub.com(util.go:421-430) and picks a transport by precedence (util.go:340-361): token → reuse an existing remote's scheme for that host → default SSH. - Your git config has URL-named promisor remotes left by
filtered_fetches(remote.git@github.com:entireio/cli-checkpoints.git.promisor trueetc.), so step 2 matches SSH — and even without them, step 3 defaults to SSH anyway. Result: checkpoints push/fetch overgit@github.com:entireio/cli-checkpoints.git. GetCheckpointRemote(cmd/entire/cli/settings/settings.go:1399) only accepts{provider, repo}with provider ∈ {github, gitlab} — no raw-URL form, no "entire" provider. So no settings.json edit can route the checkpoint repo through the mirror today.
Your options:
- Delete the
checkpoint_remoteblock — checkpoints then push to origin, i.e. through theentire://mirror, but they land onentire/checkpoints/v1ofentireio/cliitself instead of the separatecli-checkpointsrepo. Tradeoff: you lose the separate-repo isolation, gain full mirror routing immediately. - Keep the separate repo, add the feature — teach
checkpoint_remoteto accept anentire://target (e.g.{"url": "entire://<cluster>/gh/entireio/cli-checkpoints"}), plus create a push-through mirror forcli-checkpoints. That's a CLI change incheckpoint/remote/util.go+settings.go.
Side observations: the remote.entire://eukanuba.partial.to/... promisor entry is a stale leftover from an old mirror host, and remote.origin.entiredb-original-url confirms origin was already migrated off SSH — so the checkpoint path is the only SSH user left in this repo's config.
Want me to implement option 2 (an entire://-capable checkpoint remote), or just flip you to option 1?
yes we need to add the feature. make it so our tool understands how to push to entire://, then configure the checkpoint remote to use that. the cluster we'll use is entire://aws-ap-southeast-2.entire.io.
Done — committed as 855b8cdab on swirling-doodling-waffle (not pushed, per your rules).
Bottom line: Checkpoints now follow origin through the mirror: with your existing settings, the checkpoint URL resolves to entire://aws-ap-southeast-2.entire.io/gh/entireio/cli-checkpoints — no settings.json edit needed, and I confirmed that mirror is live.
What changed:
deriveCheckpointURLFromInfo(cmd/entire/cli/checkpoint/remote/util.go:302) gained anentirecase: keep the cluster host and forge, swap in the checkpoint repo. Guarded so the forge must map to the configured provider (gh↔ github) — a forge-mismatched mirror orfile://origin still falls back to provider-host routing, and fork-owner detection still applies.ENTIRE_CHECKPOINT_TOKENstill forceshttps://github.com/...(CI has no helper auth; the token can't ride throughentire://).- Flipped
TestPushURL_EntireOriginReusesProviderRemoteScheme(which pinned the old "route to GitHub" behavior from regression #1279) intoTestPushURL_EntireOriginDerivesMirrorURL, reproducing your exact setup — entire:// origin on aws-ap-southeast-2 plus leftovergit@github.compromisor remotes — and asserting they no longer divert checkpoints off the mirror. Updated the test-plan doc rows that documented #1279.
Why no config change: the resolver's design derives transport from the push remote, so the cluster is inherited from origin — which is already entire://aws-ap-southeast-2.entire.io/gh/entireio/cli. This also keeps the committed settings.json portable: teammates on SSH origins keep SSH, anyone on a mirror uses their mirror, all landing in the same cli-checkpoints repo. Tradeoff: if you ever want the cluster pinned independent of origin, that needs an explicit URL-form config we didn't add.
Verified: mise run fmt && mise run lint clean (diff checked after), targeted package tests pass (checkpoint/..., gitremote, settings, strategy), and git ls-remote entire://aws-ap-southeast-2.entire.io/gh/entireio/cli-checkpoints returns HEAD plus existing checkpoint refs. Full suite left to CI per your preference. Your next real push's pre-push hook is the live confirmation — the checkpoint leg should dial the cluster instead of opening an SSH connection to github.com.
One inert leftover: the shared .git/config still has git@github.com:... promisor entries from old filtered fetches. They're harmless (fetches will now create an entire:// promisor entry), and I left the shared config untouched from this worktree.