.devcontainer\mssql\installSQLtools.sh fail to run when building images on Windows (Git issue)

[doggy8088]

• VSCode Version: 1.70.0
• Local OS Version: Microsoft Windows [Version 10.0.19043.1826]
• Remote OS Version: Ubuntu 20.04.4 LTS
• Remote Extension/Connection Type: Containers
• Logs: N/A

Steps to Reproduce:

1. create new .net 6 project and open with vscode

   dotnet new web -n web1
   code web1

2. F1 > Remote-Containers: Add Development Container Configuration Files

3. Choose C# (.NET) and MS SQL

   

4. Choose 6.0-focal (.NET version)

5. Choose none (Node.js version)

6. Hit OK

   At this moment, the .devcontainer\mssql\installSQLtools.sh file is LF which is correct.

7. Initialize Git

   dotnet new gitignore
   
   git init
   git add .
   git commit -m "Initial commit"

At this moment, nothing wrong here. But if you git push to the remote and somebody use Windows to git clone again. The problem will appear.

Git for Windows set core.autocrlf config to true by default. Which means all text file are use CRLF as a default new line characters. That will cause .devcontainer\mssql\installSQLtools.sh file become CRLF at that moment which is WRONG.

Then you can try to build Dockerfile and the error will happen.

cd .devcontainer
docker-compose build --no-cache

[+] Building 1.4s (8/8) FINISHED
 => [internal] load build definition from Dockerfile                                                                                                           0.0s 
 => => transferring dockerfile: 32B                                                                                                                            0.0s 
 => [internal] load .dockerignore                                                                                                                              0.0s 
 => => transferring context: 2B                                                                                                                                0.0s 
 => [internal] load metadata for mcr.microsoft.com/vscode/devcontainers/dotnet:0-6.0-focal                                                                     0.3s 
 => CACHED [1/4] FROM mcr.microsoft.com/vscode/devcontainers/dotnet:0-6.0-focal@sha256:256a191ceb1123e5b40fa8be91c6ce44c2db6d5be12036c6944edc7cd1a80739        0.0s 
 => [internal] load build context                                                                                                                              0.0s 
 => => transferring context: 786B                                                                                                                              0.0s 
 => [2/4] RUN if [ "none" != "none" ]; then su vscode -c "umask 0002 && . /usr/local/share/nvm/nvm.sh && nvm install none 2>&1"; fi                            0.4s 
 => [3/4] COPY mssql/installSQLtools.sh installSQLtools.sh                                                                                                     0.0s 
 => ERROR [4/4] RUN bash ./installSQLtools.sh      && apt-get clean -y && rm -rf /var/lib/apt/lists/* /tmp/library-scripts                                     0.5s 
------
 > [4/4] RUN bash ./installSQLtools.sh      && apt-get clean -y && rm -rf /var/lib/apt/lists/* /tmp/library-scripts:
#0 0.491 Installing mssql-tools
#0 0.491 ./installSQLtools.sh: line 3: syntax error near unexpected token `$'\r''
'0 0.491 ./installSQLtools.sh: line 3: `curl -sSL https://packages.microsoft.com/keys/microsoft.asc | (OUT=$(apt-key add - 2>&1) || echo $OUT)
------
failed to solve: executor failed running [/bin/sh -c bash ./installSQLtools.sh      && apt-get clean -y && rm -rf /var/lib/apt/lists/* /tmp/library-scripts]: exit code: 2

I would like to suggest you can put a .gitattributes file with the following content to the .devcontainer\mssql\ folder.

*.sh    text eol=lf

That will solve the problem I mentioned for Windows users.

I think this issue related to various different projects. This should be take cared.

[bluementat]

Has there been any updates on this issue? I experienced it while starting with dev containers. @doggy8088 's fix worked, however.