fix(docker): normalize CRLF line endings on Windows checkouts#951
fix(docker): normalize CRLF line endings on Windows checkouts#951sridhar-3009 wants to merge 1 commit into
Conversation
A Windows Git checkout with checkout-time CRLF conversion enabled produces CRLF working-tree copies of package.json and scripts/rocm-entrypoint.sh, breaking the Docker build two ways: - The frontend stage's `sed -i -z 's/,\n ]/…/'` is LF-anchored, so it doesn't match against \r\n and leaves an invalid trailing comma in package.json, which then fails JSON parsing in the vite build. - The final stage copies rocm-entrypoint.sh straight from the build context; with a CRLF shebang the container reports the misleading "no such file or directory" for an entrypoint that plainly exists, because Linux can't resolve "/bin/sh\r" as an interpreter. Add .gitattributes forcing LF for both files at checkout time, plus a sed normalization step in each Dockerfile stage for resilience with clones that predate the .gitattributes rule. Fixes jamiepine#915
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe changes enforce LF endings for ChangesLine-ending normalization
Estimated code review effort: 2 (Simple) | ~5 minutes Possibly related issues
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Checkov (3.3.8)DockerfileTraceback (most recent call last): Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Fixes #915.
Problem
A Windows Git checkout with checkout-time CRLF conversion enabled produces CRLF working-tree copies of
package.jsonandscripts/rocm-entrypoint.sh, breakingdocker compose build/uptwo independent ways:sed -i -z 's/,\n ]/\n ]/'is LF-anchored and doesn't match,\r\n ], so the"web",entry's trailing comma survives after"tauri"/"landing"are stripped, producing invalid JSON that fails the Vite build (JSON does not support trailing commas).scripts/rocm-entrypoint.shstraight from the build context. With a CRLF shebang, the effective interpreter path becomes/bin/sh\r, which Linux can't resolve — surfaced as the misleadingexec /usr/local/bin/entrypoint.sh: no such file or directoryeven though the file is right there.Fix
Two parts, both suggested in the issue:
.gitattributesforcing LF for both files at checkout time going forward:sed -i 's/\r$//'normalization step in each Dockerfile stage (before the trailing-comma fixup, and right after copying the entrypoint script) for resilience with clones that predate the.gitattributesrule.Testing
I don't have a Windows machine to reproduce the CRLF checkout directly, so I verified the regex behavior conceptually:
sed's-zmode splits on NUL only, so\rbefore the matched\nis preserved as part of the "non-newline" content and defeats the pattern's,\nanchor exactly as described. I didn't run the fulldocker compose buildend-to-end. Happy to adjust if you can verify against a real CRLF checkout.Summary by CodeRabbit