jamesfredley opened a new pull request, #15622: URL: https://github.com/apache/grails-core/pull/15622
## Summary 7.0.x companion to apache/grails-core#15620. Pin the line endings of shell scripts, `gradlew`, `KEYS`, and the Dockerfile to LF on every platform, and add a defensive `sed` strip step in `etc/bin/Dockerfile`, so the release verification container is reproducible from a Windows committer's checkout. ## Why There is no `.gitattributes` in the repo today. With Git for Windows' default `core.autocrlf=true`, every Windows checkout converts these files from LF to CRLF in the working tree. The Dockerfile's `ADD` then preserves the CRLF into the image, which produces three independent failures during release verification: 1. The Linux kernel refuses to execute scripts with `bash\r` in the shebang, so `gradlew` and every `verify-*.sh` script fail with `cannot execute: required file not found` / `/usr/bin/env: 'bash\r': No such file or directory`. 2. `verify-keys.sh` shasum-512s the in-tree `KEYS` file and compares against the canonical copy at `https://dist.apache.org/repos/dist/release/grails/KEYS`. The two byte-streams differ by exactly one `\r` per line (52 bytes total) and the comparison fails even though the content is byte-identical after normalization. 3. By extension, `verify.sh` aborts at its first step (`verify-keys.sh`) on any Windows committer's machine. The container documented in `RELEASE.md` is unusable as-is. CI on `ubuntu-latest` and any Linux/macOS verifier are unaffected. The bug is only visible to a Windows committer because git's checkout-time conversion is the layer that introduces the corruption. The line-ending bug exists identically on 7.0.x: `etc/bin/Dockerfile` and the `verify-*.sh` scripts are byte-for-byte the same as on 8.0.x (the only Dockerfile delta between branches is the JDK version - `17.0.18` here vs `21.0.7` on 8.0.x), and 7.0.x has the same identical missing-`.gitattributes` situation. ## Why fix this at the `.gitattributes` layer `.gitattributes` is the only mechanism in the repo that operates at git's working-tree write path. Other code-style mechanisms either don't run at the right time or don't cover the right files: | Tool | Audits `*.sh` / `gradlew` / `KEYS`? | Runs at checkout? | |---|---|---| | `.editorconfig` (existing - groovy/java only) | No | No (editor-time) | | Checkstyle / `codeStyle` task | No (Java/Groovy only) | No (build-time) | | CodeNarc | No (Groovy only; LineEnding rule not enabled) | No (build-time) | | `.gitattributes` (this PR) | Yes | **Yes** | ## Changes ### `.gitattributes` (new) - `* text=auto` - sane default; git auto-detects text vs binary, stores text as LF in the index - `*.sh`, `gradlew`, `KEYS`, `Dockerfile`, `*.properties` -> `text eol=lf` (must be LF on Linux verifier and CI) - `*.bat`, `*.cmd`, `gradlew.bat` -> `text eol=crlf` (must be CRLF on Windows) - Common binary types (`*.jar`, `*.zip`, `*.png`, `*.pdf`, `*.gpg`, `*.keystore`, ...) marked `binary` so git never normalizes them ### `etc/bin/Dockerfile` Add a `RUN sed -i 's/\r$//'` step after the `ADD` lines, scoped to `*.sh`, `gradlew`, `KEYS`, and `*.properties`. This is belt-and-braces: even if a committer's working tree still has CRLF (because their local checkout predates this PR and they have not re-checked-out / renormalized), the image they build will still be correct. ## Index impact Verified ahead of time on the 7.0.x worktree: ` $ git ls-files --eol gradlew etc/bin/verify.sh KEYS gradlew.bat etc/bin/Dockerfile i/lf w/lf attr/text eol=lf KEYS i/lf w/lf attr/text eol=lf etc/bin/Dockerfile i/lf w/lf attr/text eol=lf etc/bin/verify.sh i/lf w/lf attr/text eol=lf gradlew i/crlf w/crlf attr/text eol=crlf gradlew.bat ` Every affected file is **already LF in the index**. This PR therefore does not require `git add --renormalize .` and does not produce any blob churn - it only changes what `git checkout` writes to disk on the next checkout, and pins the contract going forward. ## Related - Companion PR: apache/grails-core#15620 (same fix on `8.0.x`). With both PRs merged, the container verification flow is reproducible on every platform for both the 7.0.x maintenance line and the 8.0.x development line. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
