Windows shell executor (bash) fails with 1.4.0: "GIT_SSL_CAINFO: No such file or directory"

I updated from gitlab-runner 1.3.0 to 1.4.0 and now my builds fail with the following message

Running with gitlab-ci-multi-runner 1.4.0 (5dd9b2f)
Using Shell executor...
Running on BUILD1...
bash: line 51: /e/Multi-Runner/E:/Multi-Runner/builds/483a0fb2/0/my-namespace/my-project.tmp/GIT_SSL_CAINFO: No such file or directory
ERROR: Build failed: exit status 1

The file E:/Multi-Runner/builds/483a0fb2/0/my-namespace/my-project.tmp/GIT_SSL_CAINFO exists. Since I am using shell executor with bash on windows. The path to the file should be:

• /e/Multi-Runner/builds/483a0fb2/0/my-namespace/my-project.tmp/GIT_SSL_CAINFO and not
• /e/Multi-Runner/E:/Multi-Runner/builds/483a0fb2/0/my-namespace/my-project.tmp/GIT_SSL_CAINFO

This is my config.toml

concurrent = 3

[[runners]]
  name = "BUILD1"
  url = "https://git.domain.tld/ci"
  token = "..."
  tls-ca-file = ""
  executor = "shell"
  shell = "bash"
  [runners.ssh]
  [runners.docker]
    image = ""
    privileged = false
  [runners.parallels]
    base_name = ""
  [runners.virtualbox]
    base_name = ""

After downgrade to gitlab-runner 1.3.0 the builds succed again.

Running into the exact same issue after upgrading to 1.4.0 (fine with 1.3.2).

Thanks for report. We'll look on this.

Milestone changed to %v1.4

Added ~58730 label

Added regression label

Same here. I upgraded today to 1.4.1.

The 'builds_dir' is set to "D:\ci" in the config, the runner is installed to "C:\Multi-Runner" and the builds fail with this error:

bash: line 40: /c/Multi-Runner/D:/ci/baf9fd9c/0/CMIC/NifTK.tmp/GIT_SSL_CAINFO: No such file or directory
ERROR: Build failed: exit status 1

I downgraded to 1.3.4 and it works well.

This reminds me of the issue #1233 (closed) and !216 (merged) related to wrong path strings with bash on windows.

Is there a section for 'Older downloads' so I can get, for example, 1.3.4? I could build it myself, but I would be easier for my team to have an url.

How are the new releases tested so that these regressions won't show up in the future?

mentioned in issue #1523 (closed)

@ph03 We are testing that on Linux machines for now. Currently we are working on adding a separate Windows and Mac machines to test this type of regressions.

@erandros https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/bleeding-edge.md#download-any-other-tagged-release (the same applies to .rpm and .deb files)

I got the same problem with shell = "bash" on Windows:

Running with gitlab-ci-multi-runner 1.4.1 (fae8f18)
Using Shell executor...
Running on MH...
/usr/bin/bash: line 43: /d/Programs/GitLab_CI/D:/Programs/GitLab_CI/builds/8d2dc509/0/michael.huepkes/gitLabTest.tmp/GIT_SSL_CAINFO: No such file or directory
ERROR: Build failed: exit status 1

I have the same issue on gitlab-ci-multi-runner 1.4.2 (bcc1794)

dito here Even with bleeding edge 1.5.0~beta Would be good to see a fix soon. Thanks!

same issue still exists in 1.5.2:

Running with gitlab-ci-multi-runner 1.5.2 (76fdacd)
Using Shell executor...
Running on xxx...
bash: Zeile 44: /home/yyy/c:/gitlab-runner/builds/f808858f/0/grp-aaa/bbb.tmp/GIT_SSL_CAINFO: No such file or directory
ERROR: Build failed: exit status 1

Milestone changed to %Backlog

And what about solution? GitLab CI can not work with windows. I can not run specific bat file in C:\dir.

Ayeayeaye. Good spot. This will be caused by the "Absolute" helper in shells/bash.go

The Bash generator assumes it's running in a UNIXy environment, so its check for "is this an absolute path?" is "does this path start with the / character?" - which is wrong on Windows, of course.

I'll see if I can come up with something, but it's unlikely to be for 1.6 :/

Mentioned in issue #1687

Just a frindly reminder that you can still downgrade to gitlab runner 1.3.x which still runs fine with the current gitlab release (unless you need some 1.4 / 1.5 features of course).

According to https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/CHANGELOG.md this bug is most likly introduced with Fix Absolute method for absolute path discovering for bash (1.4.0)

@nick.thomas I would say that this is not a problem of using Absolute() and that it uses path rather then filepath.

The problem is that the b.TemporaryPath is set to E:/Multi-Runner/... when in Windows' bash it should be in the /e/Multi-Runner/... syntax. If the path would be set as it is used on Windows, then it would look as a standard unix path with the / on the beginning (and the Absolute function would work as it's working on Unix).

I think we should:

1. Determine how Windows is preparing the path's for its bash. Is it always X: => /x/ or maybe there are any other rules?
2. Update this line: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/shells/bash.go#L200 to set a proper TemporaryPath for the bash writer.

Doing a quick research:

• https://msdn.microsoft.com/en-us/commandline/wsl/faq: the "How do I access my C drive?" part,
• https://blogs.windows.com/buildingapps/2016/07/22/fun-with-the-windows-subsystem-for-linux/: the "Working with Windows files" part,

both suggest that each drive available for Windows exists as the /mnt/[lower-case-driver-letter]/.

We could try to do a simple rewrite from X: to /mnt/x/ when setting the TemporaryPath and check if this works.

Bash != Windows Subsystem for Linux.

Path is just /c/path/to/runner/...

@j-steinblock Yes, those are descriptions for WSL introducecd in latest Windows version.

Bash can be used on Windows in several ways:

• WSL
• cygwin
• bash bundled with git for Windows (MSGit? don't remember the name now; I know there are two commonly used git packages for windows and one of them includes a bash shell)

Few years ago I've used something else so there are probably other options to use bash on Windows.

Is path converted the same way in all cases? I'd like to avoid doing a path discovering like if pathExist("/c/...") {} elseif pathExists("/mnt/c/...") {} elseif pathExist("/other/option/") {} for each known possibility if there is some standardized way of converting paths when using bash on windows. Maybe you known any documents that are describing it?

We should probably make this paths to be deduced from current $PWD in build script. It should effectively solve that in all cases that we have.

Upgraded and got bit by this. I wanted some newer gitlab-runner features, so I had to switch to the cmd executor and move a lot of the functionality in my .gitlab-ci.yaml into a separate .sh file so I could execute that from the yaml file via "bash -c".

Just so others know, that is usually a valid workaround for this.

But man it would have been nice not to have to do that :)

This error is still present in v1.6.0 - is there an eta for a potential fix? We are using the same bash scripts for builds on windows + linux, and having to rewrite the scripts for windows is not a viable option, as they used to work before.

It would be good to see a fix soon, frustrating to see no assignee on this critical issue :-(

1.7.1 and still getting the error. Well, looks like this won't be fixed and I don't understand how to fix it on my side. ¯_(ツ)_/¯ Moving on...

Got the same using bleeding edge. Cc @tmaczukin Thought that !216 (merged) would solve it.

Running with gitlab-ci-multi-runner 1.8.0~beta.3.g51eb636 (51eb636)
Using Shell executor...
Running on GIMLI...
bash: line 54: /d/gitlab-ci-runner/D:/gitlab-ci-runner/builds/88a9dbf3/0/gitlab/duopo/mapa-franquias.tmp/GIT_SSL_CAINFO: No such file or directory
ERROR: Build failed: exit status 1

using builds_dir and cache_dir at config.toml seems to be a workaround.

@junalmeida's solution worked for me.

I added the following to the toml and everything started working

builds_dir="/c/Multi-Runner/builds/"
builds_cache="/c/Multi-Runner/cache/"

@junalmeida @brians1196 Thank you so much!!!

@brians1196

I followed your instructions some time ago and finally manged to update from runner 1.3 to 1.10. However, today I figured out that caching was broken since the update. Not a huge impact (10-20 secs per job) for me, but it should be

builds_dir="/c/Multi-Runner/builds/"
cache_dir="/c/Multi-Runner/cache/"

according to Advanced configuration

Btw. Issue still not fixed with 1.11.1

Thanks for letting me know. That was a typo on my part.