feat: wire up drift scanner with GitHub API comparison#3
feat: wire up drift scanner with GitHub API comparison#3jmanhype wants to merge 1 commit intoagentjido:mainfrom
Conversation
Replace the has_drift? stub with a real implementation that uses
`gh api repos/{owner}/{repo}/compare/{sha}...HEAD` to detect
whether source files have changed since a Livebook was last grounded.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3183d84ad5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| {owner, repo} = parse_repo_spec(repo_spec) | ||
|
|
||
| Enum.any?(source_files, fn file -> | ||
| case System.cmd("gh", ["api", "repos/#{owner}/#{repo}/compare/#{last_sha}...HEAD", |
There was a problem hiding this comment.
This System.cmd/3 call will raise :enoent if gh is not installed or not on PATH, so the task crashes before it can reach the non-zero fallback branch. In environments that run docs tooling without GitHub CLI, mix jido_lib.github.docs.scan_drift aborts instead of reporting an unverifiable repo as potential drift. Add an executable check or rescue around the command invocation so this failure mode is handled.
Useful? React with 👍 / 👎.
| Enum.any?(source_files, fn file -> | ||
| case System.cmd("gh", ["api", "repos/#{owner}/#{repo}/compare/#{last_sha}...HEAD", | ||
| "--jq", ".files[].filename"], stderr_to_stdout: true) do |
There was a problem hiding this comment.
The compare API request does not depend on file, but it is executed inside the source_files loop, creating redundant repos × source_files calls. This significantly increases latency and the chance of throttling/transient failures, and any single failure returns true, which marks drift even when no tracked files changed. Move the compare call outside the inner loop and reuse the changed-file list for membership checks.
Useful? React with 👍 / 👎.
1 participant
Summary
has_drift?/3stub inScanDriftwith a real implementationgh api repos/{owner}/{repo}/compare/{sha}...HEADto detect whether source files have changed since a Livebook was last groundedparse_repo_spec/1to handleowner/repo:aliasformatContext
This completes the Drift Scanner (Pillar 5 of the Autonomous Documentation Engine). The scan task can now detect when upstream source code changes invalidate existing generated Livebooks.
Test plan
mix jido_lib.github.docs.scan_drift priv/pages/docsagainst a repo with generated Livebooksgrounded_shaare flagged as driftedgrounded_shaare skipped gracefully🤖 Generated with Claude Code