fix(ci): add fork workflow sync check for community PRs#147
fix(ci): add fork workflow sync check for community PRs#147
Conversation
013013e to
09c54ce
Compare
Keith-CY
left a comment
There was a problem hiding this comment.
Two blockers remain in this revision:
-
This switches multiple workflows to
pull_request_targetand then checks outrefs/pull/<n>/mergeand runs PR-controlled code from that checkout (bun install,npm ci,cargo llvm-cov,cargo test,docker build, etc.). That is the unsafepull_request_targetpattern for fork PRs. The worst case isscreenshot.yml, which grantscontents: write, builds PR-controlled Docker context, and then pushes back to the repository. GitHub recommends avoidingpull_request_targetunless privileged context is strictly necessary, and workflows using it must not explicitly check out untrusted code. A safer shape is to keep execution workflows onpull_requestand use a separate metadata-only privileged workflow (workflow_runor similar) to post comments. -
screenshot.ymlnow triggers onpull_request_target, but the final comment steps still requiregithub.event_name == pull_request, so the screenshot comment will never be created or updated.
There is also a correctness regression in coverage.yml and metrics.yml: their concurrency keys still use github.ref, which under pull_request_target is the base branch ref, so unrelated PRs to the same base can cancel each other.
Fork PRs include their own .github/workflows/ files in the merge commit. If the fork is behind upstream, CI runs stale workflows that reference deleted files or lack recent fixes — causing confusing failures. Solution: add a lightweight check step (fork PRs only) after checkout that compares .github/workflows/ against the base branch. If files differ, the job fails immediately with clear sync instructions. - ci.yml, coverage.yml, home-perf-e2e.yml, metrics.yml, pr-build.yml, screenshot.yml: add fork workflow sync verification step - e2e.yml: skip fork PRs entirely (requires repo secrets) - No trigger changes — keeps pull_request (safe, testable) - No security implications — no elevated permissions for fork code
09c54ce to
356608b
Compare
📊 Test Coverage Report
Coverage measured by |
|
Closing — fork CI sync issues can be resolved through contributor communication (asking them to sync their fork with upstream). |
📸 UI ScreenshotsCommit: Light Mode — Core Pages
Dark Mode
Responsive + Dialogs
|
📏 Metrics Gate ReportStatus: ✅ All gates passed Commit Size ✅
Bundle Size ✅
Perf Metrics E2E ✅
Command Perf (local) ✅
Local command timings
Command Perf (remote SSH) ✅
Remote command timings (via Docker SSH)
Home Page Render Probes (real IPC) ✅
Code Readability
|
📦 PR Build Artifacts
|

























Problem
Fork PRs (e.g. #142) include stale
.github/workflows/files from the fork. GitHub runs these stale workflows in the merge commit, causing confusing CI failures (missing files, wrong refs, permission errors).Solution
Add a lightweight fork workflow sync check step after checkout in all PR-triggered workflows. For fork PRs only, it compares
.github/workflows/against the base branch — if files differ, the job fails immediately with clear instructions:Changes:
Why not
pull_request_target?pull_request_target+ checkout PR code = security risk (untrusted code runs with write permissions). Keepingpull_requesttrigger is safe and testable.Trade-off
Fork contributors need to sync their
.github/workflows/directory before CI will run. This is a one-time step per sync and the error message tells them exactly what to do.Fixes CI for #142.