Trigger codegraph snapshot rebuild on main push#7778
Conversation
Sends a repository_dispatch to ethyca/codegraph to rebuild the knowledge graph snapshot whenever fides main gets a new commit. The snapshot is used by CI code-review workflows for structural analysis. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
There was a problem hiding this comment.
Clean, focused workflow that follows the existing trigger_fidesplus_builds.yml pattern well. A couple of minor notes:
Suggestions
peter-evans/repository-dispatch@v3uses a mutable tag whileactions/create-github-app-tokenis pinned to a full commit SHA — worth pinning both for supply chain consistency.
Nice to have
- A
concurrencygroup (cancel-in-progress) would avoid queuing redundant rebuilds when multiple commits land on main in quick succession.
Otherwise the logic is straightforward and correct — using ${{ github.sha }} directly avoids the need for a checkout step, the GitHub App token pattern is a good call, and the workflow_dispatch trigger is useful for manual resyncs.
| uses: peter-evans/repository-dispatch@v3 | ||
| with: | ||
| token: ${{ steps.cross-repo-token.outputs.token }} | ||
| repository: ethyca/codegraph |
There was a problem hiding this comment.
Suggestion: Pin peter-evans/repository-dispatch to a full commit SHA
actions/create-github-app-token is pinned to a specific commit hash (fee1f7d63c2ff003460e3d139729b119787bc349), but peter-evans/repository-dispatch@v3 uses a mutable tag. A mutable tag can be force-pushed by the upstream maintainer, which is a supply chain risk — a compromised tag could execute arbitrary code in this workflow.
Consider pinning to the commit SHA for v3, e.g.:
uses: peter-evans/repository-dispatch@ce57c68e63d0b9b4429076b60fa0f8f50de4cb40 # v3You can find the SHA via git ls-remote https://github.com/peter-evans/repository-dispatch refs/tags/v3.
| push: | ||
| branches: [main] | ||
| workflow_dispatch: | ||
|
|
There was a problem hiding this comment.
Nice to have: Add a concurrency group to avoid redundant snapshot rebuilds
If several commits land on main in quick succession (e.g. a merge train or a batch of rebased commits), this workflow will queue a rebuild for each one. Since each new commit supersedes the previous snapshot, only the latest matters. A concurrency group that cancels in-progress runs would avoid wasted work in the codegraph repo:
concurrency:
group: codegraph-snapshot
cancel-in-progress: trueLow-priority — depends on how the codegraph rebuild handles concurrent triggers — but worth considering if rebuilds are expensive.
|
Updated blocker (simplified): |
repository_dispatch requires write access. Reuse the existing DISPATCH_ACCESS_TOKEN PAT (same as trigger_fidesplus_builds.yml) so the GitHub App can stay read-only. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Closing — we're switching to a 4-hour snapshot schedule in codegraph instead of per-commit repository_dispatch triggers. Simpler and avoids cross-repo PAT scope requirements. |
Summary
Sends a
repository_dispatchevent toethyca/codegraphwhenever fides main gets a new commit. This triggers a rebuild of the codegraph knowledge graph snapshot used by CI code-review workflows.Uses the
ethyca-cross-repoGitHub App token (same pattern astrigger_fidesplus_builds.yml).Required setup
CROSS_REPO_APP_IDvar andCROSS_REPO_APP_PRIVATE_KEYsecret configured in fides repo settingsTest plan
🤖 Generated with Claude Code