Pin LF, because the deployment target is a Linux container

core.autocrlf=true gave the checkout CRLF .py and .yaml. run.sh happened to be LF, which is the only reason a plain copy would not have produced a "bad interpreter" failure on the add-on's entrypoint. 0.3.0 was deployed by extracting from git with autocrlf forced off and verified byte-identical to the blobs before copying. This makes that the default rather than something the deployer has to remember. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
DEPLOY-01: 0.3.0, so the update is installable at all
2026-08-25 16:01:44 +02:00 · 2026-08-25 15:52:47 +02:00
1 changed files with 10 additions and 0 deletions
@@ -0,0 +1,10 @@
 # This add-on is deployed to a Linux container. core.autocrlf=true on the
 # authoring box gave the checkout CRLF, so a plain copy shipped CRLF files -
 # run.sh with CRLF is a "bad interpreter" failure, and any hash-based drift
 # check between repo and deployment fails for a reason that has nothing to do
 # with the code. Deploy with:
 #     git -c core.autocrlf=false archive release/1.0 goodwe_controller | tar -x
 # which is how 0.3.0 went out, byte-identical to the blobs.
 * text=auto eol=lf
 *.png binary
 *.gz  binary