docker run -it --rm --entrypoint /bin/bash gcr.io/insomnia-api-staging/helmfile -c "file /builder/helmfile.bash"
/builder/helmfile.bash: Bourne-Again shell script, ASCII text executable
Builds using the default entrypoint should succeed as expected.
Actual Behavior
docker run -it --rm --entrypoint /bin/bash gcr.io/insomnia-api-staging/helmfile -c "file /builder/helmfile.bash"
/builder/helmfile.bash: Bourne-Again shell script, ASCII text executable, with CRLF line terminators
Builds using the default entrypoint fail as follows:
standard_init_linux.go:228: exec user process caused: no such file or directory
Steps to Reproduce the Problem
Clone GoogleCloudPlatform/cloud-builders-community on Windows
cd cloud-builders-community/helmfile
gcloud builds submit --config .\cloudbuild.yaml
Start pipeline using resulting image
Observe failure.
Additional Info
It'd be possible to fix this issue with a .gitattributes file to at least prevent autocrlf from touching bash scripts. However, as of now I don't see any such files in this repo.
This issue likely affects other images here. It'd probably be good to just use .gitattributes to entirely override autocrlf behavior.
Affected builder image
gcr.io/cloud-builders-community/helmfile
Expected Behavior
Builds using the default entrypoint should succeed as expected.
Actual Behavior
Builds using the default entrypoint fail as follows:
Steps to Reproduce the Problem
GoogleCloudPlatform/cloud-builders-community
on Windowscd cloud-builders-community/helmfile
gcloud builds submit --config .\cloudbuild.yaml
Additional Info
It'd be possible to fix this issue with a
.gitattributes
file to at least preventautocrlf
from touching bash scripts. However, as of now I don't see any such files in this repo.This issue likely affects other images here. It'd probably be good to just use
.gitattributes
to entirely overrideautocrlf
behavior.