fix(ci): trust the checkout inside image-push-manual's bazel-ci container - #1335
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 12 included reviews per hour; 11 remain after this review. 📝 WalkthroughWalkthroughThe manual image push workflow now marks the checked-out workspace as a trusted Git directory inside the container before Git-dependent build steps run. ChangesManual image push workflow
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This CI-only change addresses commit labeling in manually pushed images, and no actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
…iner git rev-parse fails silently with "dubious ownership" (CVE-2022-24765) when the bazel-ci container job runs against a checkout owned by the runner host's UID, so workspace_status.sh falls back to the literal "unknown" and event-ledger's manual-dispatch images embed mr-unknown instead of a real short SHA. Signed-off-by: priyaselvaganesan <pselvaganesa@nvidia.com>
a4f2e82 to
c035868
Compare
TL;DR
event-ledger's manual-dispatch images embed
mr-unknowninstead of a real commit short SHA. Adds a step to trust the checkout inside thebazel-cicontainer sogit rev-parsestops failing silently.Additional Details
image-push-manual.yml'spush to ncp-devjob runs insidecontainer: ghcr.io/nvidia/nvcf/bazel-ci.actions/checkoutclones on the runner host; the container then mounts that checkout under a different UID. Since git 2.35.2 (CVE-2022-24765), git refuses to operate on a repo it does not own ("detected dubious ownership").tools/workspace_status.sh'sgit rev-parse --short HEAD 2>/dev/null || echo "unknown"swallows that failure and silently falls back to the literal"unknown", so the job log shows no error at all. This is on top of, not caused by, #1315's--stampfix: that fix got stamping to actually run, which is what surfaced this second bug.Added
git config --global --add safe.directory "$GITHUB_WORKSPACE"right after Checkout in thepushjob.For QA
Verified on a live
workflow_dispatchrun against event-ledger (run https://github.com/NVIDIA/nvcf/actions/runs/33214488561, on a scratch branch with this same fix): pulled the pushed image, extracted the binary,stringsshowsmr-0c4521ccmatching the real commit short SHA, with zero occurrences ofmr-unknown. An equivalent dispatch before this fix (run 33207590871, post-#1315 merge) producedmr-unknown.Issues
Relates to #315
Checklist