You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(GitClone): local checkout produces the same outputs as a clone (#195)
* fix(GitClone): produce the same outputs from a local checkout as from a clone
Two ways a local checkout silently came up short of the clone path's outputs,
leaving downstream blocks stuck on "Waiting for outputs from: … (repo_owner,
org_id, repo_name, repo_id)".
Remote resolution only ever looked at `origin` (GitClient.getInfo). A checkout
that names its remote something else — a fork whose upstream is the interesting
one, a repo re-pointed after `git init` — yielded no remote at all, so there was
no repo_owner/repo_name, and no org_id/repo_id either, since those are looked up
from the owner and name. inspectLocalRepo now falls back to whichever remote the
repo does have. `origin` is still preferred, so remote order decides nothing in
the common case.
The org/repo ids are resolved once, at confirm time, from the session token.
Because selecting a checkout deliberately didn't wait on the linked auth block,
confirming before authenticating produced a block permanently missing org_id and
repo_id. Confirming now waits for the auth block exactly as cloning does; the
path field, the folder picker, and the inline "is this a git repo?" check stay
usable while it's pending, since none of those need credentials.
Docs updated: the local source no longer claims to need no credentials, and the
no-remote caution now names the outputs that go missing with it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(GitClone): stop the local-checkout preview from reading as a finished block
The "is this a git repo?" check rendered in the same green success styling as
the completed state — check icon, root, remote, branch, file count — so a
checked directory looked like a block that had run. It hasn't: nothing is
registered and no outputs exist until "Use This Repo" is confirmed, and a block
that has produced no outputs leaves every consumer reporting each referenced
name as missing ("Waiting for outputs from: clone_repo (repo_owner, org_id,
repo_name, repo_id)") — which reads as the outputs being unsupported rather than
the block being unfinished.
The preview is now informational rather than success-styled, green being
reserved for the completed state, and says outright that the directory is not in
use yet. The no-remote warning names the outputs that go missing with it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* uptick to 0.21.1
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(GitClone): address review — docs contradictions and interrupt-safe git queries
Three findings from the review of #195.
The docs said choosing a directory "reads it only" and in the same sentence that
it "registers the repo exactly as a clone would" — the contradiction at the
heart of the reported bug. Inspection and confirmation are now described as the
separate steps they are, including that a block which hasn't been confirmed has
produced nothing and leaves its consumers reporting missing outputs.
The integration paragraph still said a pull request opens against the checkout's
`origin` remote, which contradicts the new fallback two paragraphs below it. It
now says "the checkout's remote".
firstRemoteUrl spawned git without ever killing the child, so an interrupted
fiber would orphan it. Rather than plumbing a Scope through inspectLocalRepo and
the handler — which would leave this helper inconsistent with countFiles three
lines away, which has the same property and is shared with the clone path —
the shared readGitLines helper wraps its drain in Effect.ensuring(kill). Same
guarantee, no signature change, no interruption path exists today anyway: on the
normal path the process has already exited and the signal is a no-op.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: docs/src/content/docs/authoring/blocks/GitClone.mdx
+8-4Lines changed: 8 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -43,7 +43,11 @@ When paired with a `<GitHubAuth>` block, the GitClone block enables a "Browse Gi
43
43
44
44
Users often already have the repository cloned — a long-lived `infrastructure-live` checkout, a work in progress branch, a monorepo they never want to re-download. The block's source picker lets them choose **Use local checkout** and select that directory instead of cloning.
45
45
46
-
Selecting a directory reads it only: the block resolves the repository root (so any subdirectory of the checkout works), reads the `origin` remote and current branch, and registers the repo exactly as a clone would. Nothing is fetched, pulled, or modified, and no credentials are needed — the files are already there.
46
+
Choosing a directory only **inspects** it: the block resolves the repository root (so any subdirectory of the checkout works), reads the repository's remote and current branch, and counts its tracked files. Nothing is fetched, pulled, or modified, and nothing is registered yet — the directory is reported on, not adopted.
47
+
48
+
Confirming with **Use This Repo** is what registers the checkout and produces the block's outputs, exactly as a completed clone does. Until then the block has produced nothing, and any later block referencing its outputs still reports them as missing.
49
+
50
+
Inspecting a directory needs no credentials, so browsing works while a linked auth block is still pending. Confirming does wait on it, exactly as cloning does — the GitHub `org_id` / `repo_id` outputs are resolved from the session token at that moment, so adopting a checkout before authentication finishes would leave the block without them.
47
51
48
52
```mdx
49
53
<GitClone
@@ -63,10 +67,10 @@ Setting `prefilledRepoDir` starts the block on the local source. Use `source` to
Everything downstream behaves the same either way: the same `clone_path`, `repo_owner`, and `repo_name` outputs, the same `$REPO_FILES` variable, the same workspace file tree, and the same [`<GitPullRequest>`](/authoring/blocks/gitpullrequest) integration — a pull request opens against the checkout's `origin`remote and current branch.
70
+
Everything downstream behaves the same either way: the same `clone_path`, `repo_owner`, and `repo_name` outputs, the same `$REPO_FILES` variable, the same workspace file tree, and the same [`<GitPullRequest>`](/authoring/blocks/gitpullrequest) integration — a pull request opens against the checkout's remote and current branch.
67
71
68
72
<Asidetype="caution">
69
-
A checkout with no `origin`remote can still be selected, but blocks that open a pull request need one. The block says so inline when it finds no remote.
73
+
A checkout with no remote at all can still be selected, but it produces no `repo_owner` / `repo_name` (nor the GitHub ids derived from them), and blocks that open a pull request need one. The block says so inline when it finds no remote. `origin` is preferred; if the checkout names its remote something else, that one is used.
70
74
</Aside>
71
75
72
76
### Pre-filled Values
@@ -203,7 +207,7 @@ After a successful clone, the GitClone block produces outputs that can be refere
203
207
|`repo_id`| Immutable GitHub numeric ID of the repository (when a GitHub token is available) |`87654321`|
204
208
|`repo_url`| The full URL of the cloned repository |`https://github.com/acme-corp/infrastructure-live`|
205
209
206
-
For a local checkout, `clone_path` is the repository root the user selected, and `repo_owner` / `repo_name` come from its `origin` remote (omitted when the repo has no remote).
210
+
For a local checkout, `clone_path` is the repository root the user selected, and `repo_owner` / `repo_name` come from its remote — `origin`when present, otherwise whichever remote the checkout has. They are omitted entirely when the repo has no remote, which also means no `org_id` / `repo_id`, since those are looked up from the owner and name.
207
211
208
212
Reference outputs in downstream blocks using template variables:
0 commit comments