Configurate selfhosted Gitlab Runner

I’m learning how to set up self hosted runners in Gitlab with a video tutorial
(…I tried to append a direct link to it here but got an error message; just google in youtube “GitLab Self Hosted Runner (Windows)” by crudsinfotech NG)
and have naive a question about the conceptional reason for configuring the .gitlab-ci.yml file in the way presented in the video.

In suggested configuation of the runner the execution program is choosen to be ‘shell’ and the shell parameter is choosen to be ‘powershell’ (see 5:25 in the video), so the relevant excerpt of the runner config file looks something like

[[runners]]
  name = "TestRunner"
  url = Blabla.com
  token = xxxxxxxxxxxxxx
  executor = "shell"
  shell = "powershell"
 

Next - the part I actually not fully undestand - the setting up of a CI job the relevant excerpt of presented .gitlab-ci.yml file Inwould like to understand (see 7:00):


job_build:
    stage: built 
    tags: 
     - windows
    
    script:  
      - echo "Blabla"
      - cmd /c echo %PATH%
      - cmd /c echo %HOME%
      - cmd /c curl --version
      - cmd /c dir

   [...]

Question: What is the role of cmd command or/and why it is neccessary to use here?
I tried to make a script without - ie above replaced in the script part the cmd commands by

script:  
      - echo "Blabla"
      - /c echo %PATH%
      - /c echo %HOME%
      - /c curl --version
      - /c dir

but got an error.
Therefore my question is why it actually important to precompose all these shell commands by the cmd command? I thought that when above the shell parameter is set to ‘powershell’ it is clear that it’s the powershell which executes all these commands, right? Why do we need to precompose cmd “additionally”?

So wouldn’t precomposing cmd there be technically redundant as technically that all would already manageble by the powershell shell, right?

Therefore I not understand the role & neccessarity for precomposing cmd command there.
Here seems tacitly hierarchy relation: powershell can call cmd.exe but not converse.

Of course, there might be pure historical reasons. But I would like to understand if there are also conceptional & technical reasons justifying this. Could somebody explain the involved mechanism behind this?

I haven’t used windows in almost 30 years, so I don’t know the specifics of setting up runner on that, but it doesn’t seem necessary to answer your question.

I also don’t want to spend my time watching a video that is complete irrelevant to me just to help you, and especially not on a site owned by a company that makes their money spying on people.

The script in the .gitlab-ci.yml file is given basically unaltered (the yaml formatting is removed, but that’s about it) to the runner. So in the case you’re wondering about powershellis asked to execute cmd /c [...]. As said I don’t know powershell, but I’m not surprised it does not like to execute /c [...].

About your last sentence: Why at all it isn’t a surprise to you that command line like /c [...] alone - ie without precomposing cmd - not works with powershell? More precisely, it is not clear to me why here seemingly powershell needs cmd.exe as “intermediate” program. Isn’t the job of powershell - like that one of any other shell - more or less by defininition to execute line-commands of type like /c [...]. Here it looks that the powershell interposes cmd.exe for tasks for which the powershell is itself intrinsically conceived for. That seems to make cmd command there to be redundant, or do I misunderstand at this stage something. And that’s essentially what I’m asking for there.

An “auxilary” question would be what is the precise relation between powershell and cmd.exe in this context. What surprises (at least) that -as both are shells- why to execute a line-command the powershell needs to call cmd for tasks for which the former was actually already designed for. In light of this cmd in this context appear redundant.

The first post here explains a bit: How to handle command-line arguments in PowerShell - Stack Overflow

/c was probably relevent when using cmd.exe. Sounds like powershell not being used correctly. But that is something most likely a question for a Microsoft Powershell forum.

Thanks. Maybe one nitpick towards the runner config file entries I marked in first grey box above.

Due to which precise reason a failure would occure if I would replace the line in above [[runners]] file

 shell = "powershell"

by

shell = "cmd"

(I tried, but got an error; but not understand the reason)

Doesn’t this parameter simply specify which shell I want to use for the runner? If yes, why choosing cmd.exe as executing shell would throw an error, in contrast to choosing powershell?

Is seems that not every shell can be used for the runner. Is there a qualitative reason there to refuse cmd.exe as shell for the runner or - said in plain words - the people where ‘just to lazy to adjoint cmd.exe as option’ for executing shell for the runner?

According to docs: The Shell executor | GitLab

is correct for the runner configuration. As for what you then use in CI/CD, would be best to read the documentation: CI/CD YAML syntax reference | GitLab but it would suggest you aren’t putting the correct information/commands, etc for what is to be ran in the CI/CD side of things and which is why it doesn’t work. So the script: section you added is incorrect in the example you showed.

But in reality you aren’t explaining what you are trying to achieve. Are you trying to use powershell or cmd as a shell executor? Maybe give a real example of what you are trying to do than just some echo blah blah or whatever above which doesn’t make any sense whatsoever. And if you are just learning, maybe you should just start with something simple and use the Gitlab CI/CD examples from the docs that I linked. If you don’t understand the video that you watched, maybe find alternative examples and watch them instead or read information that actually explains more in what is being done. I don’t use Windows/powershell or shell executor either, I don’t touch Windows with a bargepole if I don’t have to.

Are you trying to use powershell or cmd as a shell executor?

Almost; I’m wondering why to pick powershell there as shell executor for the runner is legal, but cmd in contrast not. That’s precisely my concern.

my motivation is just to understand the technical reason for this failure, just from didactical reasons.

Maybe start by reading here: Executors | GitLab you can see all executor types, and not just shell ones.

You will also see: Types of shells supported by GitLab Runner | GitLab there is no cmd shell.

2 Likes

Because /c [...] looks like an incomplete command, when shell = bash (I believe that’s the default, shell isn’t set on the runners with executor = "shell" we have) I wouldn’t expect that starting a script line with options for bash would work either. I don’t remember the exact working but I suspect that the shell is started once and then all the lines are given to it, so options to an already started process would have no chance of working.