The GitHub Actions job "CI" on grails-core.git/fix/eol-normalization has succeeded. Run started by GitHub user jamesfredley (triggered by jamesfredley).
Head commit for run: 0cc35581ca39be8937bc2f9bdd7b21f980efdadd / James Fredley <[email protected]> fix: enforce LF line endings for shell scripts, gradlew, KEYS The release verification flow runs in a Linux container built from etc/bin/Dockerfile, but the repository had no .gitattributes. With Git for Windows' default core.autocrlf=true, every Windows checkout converts gradlew, etc/bin/*.sh, the Dockerfile, and the KEYS file from LF to CRLF in the working tree. The Dockerfile's ADD then preserves those CRLFs into the image, with three failure modes: 1. The Linux kernel refuses to execute scripts with `bash\r` in the shebang, so gradlew and every verify-*.sh script fails with "cannot execute: required file not found". 2. verify-keys.sh hashes the in-tree KEYS file and compares against https://dist.apache.org/repos/dist/release/grails/KEYS, which is stored as LF. The hashes mismatch even though the content is byte-identical after line-ending normalization. 3. By extension, verify.sh aborts at its first step on any Windows committer's machine. Fix at the right layer (git's working-tree write path): - Add .gitattributes pinning *.sh, gradlew, KEYS, Dockerfile, and *.properties to eol=lf, while keeping *.bat / *.cmd / gradlew.bat as eol=crlf and marking common binary types as binary so git never tries to normalize them. Default `* text=auto` lets git auto-detect everything else. - Add a defensive sed-strip step in etc/bin/Dockerfile after the ADD lines, so even if a committer feeds a CRLF-corrupted build context (existing local checkout under autocrlf=true), the image still ends up with LF scripts. Existing index content is unchanged: every affected file is already stored as LF in the index. This commit only changes what `git checkout` writes to the working tree on Windows and adds belt-and- braces normalization at image-build time. CI on ubuntu-latest is unaffected. Linux/macOS verifiers are unaffected. Windows verifiers can now run the container build flow documented in RELEASE.md without manual workarounds. Assisted-by: claude-code:claude-opus-4-7 Report URL: https://github.com/apache/grails-core/actions/runs/25253181405 With regards, GitHub Actions via GitBox
