Настройка конфигурации для самохостиного Gitlab Runner

Вопрос или проблема

Я учусь настраивать самообслуживаемые раннеры в GitLab, используя это видео, и у меня есть вопрос о концептуальной причине настройки файла .gitlab-ci.yml таким образом, как показано в видео.

В предложенной конфигурации раннера программа выполнения выбрана как ‘shell’, а параметр оболочки выбран как ‘powershell’ (см. 5:25 в видео), так что соответствующий фрагмент конфигурационного файла раннера выглядит следующим образом:

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

Далее – часть, которую я не совсем понимаю – настройка CI задания, соответствующий фрагмент представленного файла .gitlab-ci.yml, который я хотел бы понять (см. 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

   [...]

Вопрос: Какова роль команды cmd и/или почему ее необходимо использовать здесь?
Я пытался создать скрипт без – то есть заменить в части скрипта команды cmd на

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

но получил ошибку.
Поэтому мой вопрос – почему на самом деле важно предварительно составлять все эти команды оболочки с помощью команды cmd? Я думал, что когда выше параметр оболочки установлен в ‘powershell’, очевидно, что именно powershell выполняет все эти команды, верно? Зачем нам cmd “дополнительно”? Наивно выглядит, как будто это избыточно; есть ли обязательно причина делать это таким образом?

Так не будет ли предварительное составление cmd технически избыточным, так как технически все это уже может управляться самой оболочкой powershell?

Поэтому я не понимаю роли и необходимости предварительного составления команды cmd там.
Здесь, похоже, подразумевается иерархические отношения: powershell может вызывать cmd.exe, но не наоборот.

Конечно, могут быть чисто исторические причины. Но я хотел бы понять, есть ли также концептуальные причины, оправдывающие это. Мог бы кто-то объяснить механизм, участвующий в этом?

Ответ или решение

Конфигурация самостийного GitLab Runner: Роль команды cmd в скрипте .gitlab-ci.yml

Введение

При настройке самостийного GitLab Runner важным моментом является правильная конфигурация файла .gitlab-ci.yml. Вопрос о необходимости использования команды cmd в контексте скриптов, выполняемых через PowerShell, заслуживает детального рассмотрения.

Конфигурация GitLab Runner

Вы определили ваш GitLab Runner с использованием следующей конфигурации:

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

Данная настройка подразумевает, что все команды в CI/CD будут выполняться через PowerShell. На этом этапе действия выполняются в контексте PowerShell, но это не означает, что команды, предназначенные для работы в командной строке Windows (cmd.exe), могут быть выполнены без предварительных указаний.

Роль команды cmd

Давайте разберем строчку из вашего .gitlab-ci.yml:

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

Здесь cmd /c указывает PowerShell выполнить команду в cmd.exe. Это необходимо по нескольким причинам:

  1. Совместимость команд: Некоторые команды, такие как echo, curl, требуют специфичного синтаксиса, когда они исполняются в контексте cmd.exe. В PowerShell некоторые из этих команд могут работать иначе или могут не поддерживаться вообще без явного указывания интерпретатора.

  2. Доступ к переменным среды: Пример с переменными среды (%PATH% и %HOME%) основан на синтаксисе переменных, используемых в переменных окружения командной строки Windows (cmd). В PowerShell доступ к переменным окружения происходит через $env:VARIABLE_NAME, что создаст дополнительную путаницу, если вы не знакомы с обоими контекстами.

  3. Историческая перспектива: PowerShell был введен, чтобы предоставить более современный подход к автоматизации, однако cmd.exe по-прежнему используется во многих сценариях. Использование cmd /c позволяет обеспечить совместимость с более старыми скриптами и инструментами.

Почему ваш скрипт не работал без cmd?

Когда вы пытались заменить команды следующим образом:

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

Ошибки возникли, потому что PowerShell не распознает /c как валидный оператор для выполнения команд. В PowerShell все команды выполняются непосредственно, и предварительное указание cmd требуется для выбора нужного интерпретатора.

Заключение

Использование cmd /c в конфигурации .gitlab-ci.yml – это не просто вопрос предпочтений, а необходимость для обеспечения правильного выполнения команд в специфичном контексте. Это позволяет избежать путаницы между синтаксисом PowerShell и cmd.exe, а также обеспечивает совместимость с существующими командами и скриптами.

Правильное понимание этих концептуальных основ поможет настраивать CI/CD более эффективно и решать потенциальные проблемы, связанные с выполнением различных команд в различных средах.

Оцените материал
Добавить комментарий

Капча загружается...