Files
OpenMAIC/.gitattributes
T
Nguyễn Lê TrườngandClaude Opus 5 bbcea8a227 fix(render-service): keep the entrypoint LF so the image starts on Windows (#1027)
Cloning on Windows with Git's default `core.autocrlf=true` rewrites
`render-service/docker-entrypoint.sh` to CRLF. COPY-ing it into the Linux
image leaves the shebang as `#!/bin/sh\r`, so the kernel looks for an
interpreter whose name ends in a carriage return. The container then exits
immediately with

    exec /usr/local/bin/docker-entrypoint.sh: no such file or directory

which points at the script — a file that plainly exists and is
executable — rather than at the interpreter, so the cause is far from
obvious.

Two changes, because they cover different cases:

- `.gitattributes` marks `*.sh` as `text eol=lf`, so fresh checkouts stop
  being rewritten. This is the root-cause fix, and it also covers
  `render-service/scripts/egress-smoke.sh`.
- The Dockerfile strips CR before `chmod`. `.gitattributes` does nothing
  for clones that already hold a CRLF copy, and re-normalizing an
  existing tree is a manual step; this makes the build work regardless of
  how the tree was checked out.

Verified by building the image from a CRLF checkout and starting the
container: it comes up and `/health` returns `{"ok":true}`.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 05:51:25 -04:00

10 lines
546 B
Plaintext

# Shell scripts must keep LF endings even when checked out on Windows.
#
# With Git's default `core.autocrlf=true` on Windows, docker-entrypoint.sh is
# rewritten to CRLF at checkout. COPY-ing it into a Linux image then leaves the
# shebang reading `#!/bin/sh\r`, so the kernel looks for an interpreter whose
# name ends in a carriage return and the container exits immediately with
# `exec /usr/local/bin/docker-entrypoint.sh: no such file or directory` —
# a message that points at the script rather than at the interpreter.
*.sh text eol=lf