Visual Studio command line shell build in GitLab CI

GitLab CI/CD
1

I am trying to build with Gitlab CI and sometimes it works, and sometimes it doesn’t work. I am trying to figure out why.

I am also trying to figure out what it means when I have a line in the yaml file that is in quotes.

For example, on a windows runner, what happens if I type

before_script:
  - call env.cmd

versus this:

before_script:
  - "call env.cmd"

Should both be acceptable and work?

Without the call, it seems that there is a problem because the gitlab runner seems to break when I call certain batch files without an invocation via call.

There are strange errors, and I get this random failure, even though build.cmd definitely exists:

gitlab-ci-multi-runner 1.0.4 (014aa8c)
Using Shell executor...
Running on WPOSTMA...
Fetching changes...
HEAD is now at db574da build.cmd should return nonzero
Checking out db574daa as master...
HEAD is now at db574da... build.cmd should return nonzero
$ call env.cmd
$ echo build task begin.
build task begin.
$ call build.cmd
The syntax of the command is incorrect.
The system cannot find the path specified.
C:\glrunner\builds\e1af4fcc\0\wpostma\RamSoft.WorklistPrototype2
$ echo build task end.
build task end.

What is reporting “the syntax of the command is incorrect”? Is that a gitlab error or a windows batch file error?
How can I diagnose and troubleshoot when the runner seems to nuke the build folder? How do you troubleshoot this CI tool?

W

2

I don’t use the call keyword at all, nor I have seen it before. In our Linux runners it is sufficient to have the script in the project folder. I just use the command name and that works.

3

The syntax of the command is incorrect is a Windows Command Line error. Can you post the contents of the build.cmd file?

@Mange call is a Windows Command Line built-in, so of course you don’t have it on Linux.

4

What I’ve figured out so far:

  • This is not a problem with GitLab CI runner environment

  • This is a problem due to batch file chaining issues, a long known about gotcha.

  • Sometimes, to avoid problems, I find it better to have GitLab CI yaml tasks invoke Python script, then I can completely control the environment in which cmd.exe is started, on windows, and completely control the environment so that problems like the ones I experienced are avoided.

  • There are some glitches due to Visual Studio’s VCVARS environment batch files that were causing my issues.

  • My solution has been to not depend on the visual studio batch files and invoke them, because it creates a house of cards.

In the end this isn’t a GitLab CI issue but here are the interesting insights I have gained:

  • It would be useful when something failed to know what output that line in gitlab.ci. For example, that gitlab ci has invoked “cmd.exe /k …” plus args, and then that the next line is a response to that. Then I could try that myself and see what’s happening.

  • Right now my only Gitlab CI complaint is that exactly how it invokes Win32 shells is opaque to me. Does it call ShellExecute? Does it do a system(somestring) syscall equivalent?

W

5

Even on Windows runner, I use bash as shell. No problems at all using latest runner.

6

Which BASH shell? There isn’t one standard one that ships with Windows. So which binary bash are you using? Cygwin? MingW? Git Bash (which is Mingw)? WSL (windows subsystem for linux) bash? Other?

7

I use the one from official git for Windows. It was the obvious choice for me when using git as version control.

No problems so far