Багаторядковий рядок YAML для GitLab CI (.gitlab-ci.yml)


86

Я намагаюся написати gitlab-ci.ymlфайл, який використовує багаторядковий рядок для команди. Однак, схоже, його не аналізують. Я пробував як, так - |і - >з однаковими результатами.

stages:
  - mystage

Build:
  stage: mystage
  script:
    - |
        echo -e "
            echo 'hi';
            echo 'bye';
        "

Коли він намагається запустити, він відображається лише echo -e 'як сценарій для запуску, а не весь багаторядковий рядок. Це викликає у мене проблеми.

Яким буде правильний синтаксис, щоб написати щось подібне?


У цьому є проблема: gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/166 Мені незрозуміло, в чому проблема, оскільки ваш код повинен бути еквівалентним (достатньо) YAML запропонованим там рішенням . Ви можете спробувати додати \до своїх рядків, але я не можу сказати, спрацює це чи ні.
Йорданія, що працює

Відповіді:


37

TL; DR; Ви хочете використовувати багаторядковий скаляр YAML (для читабельності), який завантажується як однорядковий рядок, який може бути виданий командою Gitlab-CI. Для цього використовуйте простий (без лапок) скаляр у YAML, який розподілений по кількох рядках:

script:
- echo -e 
   "echo 'hi';
    echo 'bye';"

Зверніть увагу, що YAML має деякі обмеження щодо таких скалярів. Що вам неодмінно потрібно знати, так це те, що кожен наступний рядок має відступ принаймні на одну позицію більше, ніж echo -e(що відступає на дві позиції відносно вузла збору, який взагалі не відступає), і що кожен новий рядок замінюється пробілом при завантаженні (тому вам потрібно трохи подбати про те, де розмістити нові рядки).


У вашому дописі є кілька помилкових уявлень, через які ви ставите неправильне запитання.

Не існує такого поняття, як багаторядковий рядок YAML . YAML має скаляри, і деякі з цих скалярів можуть бути завантажені програмою у вигляді рядків, тоді як деякі інші будуть завантажені як цілі числа, плаваючі тощо.

Вас, очевидно, цікавлять скалярні вузли, які завантажуються як рядок, оскільки цей рядок тоді можна інтерпретувати як командний рядок. Але ви не хочете мати багаторядковий командний рядок (тобто із вбудованими новими рядками), оскільки багаторядкові сценарії не підтримуються в Gitlab CI (як зазначив @Jordan).

Для читабельності ви хочете використовувати стандартну здатність YAML завантажувати багаторядкові скаляри як однорядковий рядок.

Якщо ви не дбаєте про читабельність, можете скористатися:

- echo -e "\n    echo 'hi';\n    echo 'bye';\n"

а оскільки ваш скаляр не вказаний (тобто він починається з echo), вам не потрібно робити нічого особливого в YAML для зворотних скісних рисок або лапок.

Результат сценарію однаковий (надрукуйте порожній рядок, надрукуйте echo 'hi';на рядку з відступом чотири пробіли, надрукуйте echo 'bye';на рядку з відступом чотири пробіли.)

Якщо ви хочете використовувати багаторядковий вхід для читабельності, який завантажується як один рядок, є, по суті, два варіанти: використовувати багаторядковий площинний скаляр або використовувати складений скаляр у вашому YAML.

багаторядковий звичайний скаляр

Звичайний означає, що скаляр не вказаний у цитатах, і як і будь-яка багаторядкова річ у багаторядковій лінії YAML, означає, що наступні рядки мають бути відступними належним чином, у цьому випадку далі, ніж початковий рядок

script:
- echo -e 
   "echo 'hi';
    echo 'bye';"

нові рядки замінюються пробілами, тому не робіть:

script:
- echo -e 
   "echo 'hi';
    echo '
   bye';"

оскільки ви отримаєте видимий простір раніше bye.

Існують такі обмеження, як те, що ви не можете мати двокрапку, за якою слід пробіл у такому скалярі (що зробить це схожим на пару ключ-значення).

Немає необхідності уникати зворотних скісних рисок у звичайних скалярах, оскільки ви не можете уникнути будь-яких символів у звичайному скалярі, але, звичайно, ви можете включити зворотну скісну риску, яка потрапить у рядок, завантажений з YAML, і може мати значення для виконуваної команди з цього рядка.

складений скаляр

Складений скаляр схожий на звичайний скаляр тим, що всі (одиничні) нові рядки замінюються пробілом під час завантаження:

script:
- >
  echo -e 
  "echo 'hi';
  echo 'bye';"

Вам потрібно відступити фактичну інформацію про команду принаймні на стільки, скільки складений скалярний індикатор ( >).

На відміну від простих скалярів, подібні речі :не мають особливого значення. Отже, якщо звичайні скаляри виходять з ладу, видаючи помилку YAML, подібні складені скаляри, швидше за все, не будуть.


Я хочу написати його багаторядковий для наочності та ремонтопридатності. Хоча мій приклад є тривіальним, реальні сценарії це точно не так.
samanime

Я це можу зрозуміти. Чи буде прийнятною попередня обробка вашого читабельного файлу YAML до його обробки GitLab CI?
Антон

Я про це думав. Це додатковий крок і трохи додаткова складність, але, можливо, того варто.
samanime

Я додав можливе рішення.
Антон,

3
О, малюк. Хоча технічно правильна, ця відповідь смішно багатослівна до нечитабельності. Кожен , хто не писати парсер YAML , ймовірно , просто хоче PotatoFarmer «и високо upvoted і багато terser відповіді , натомість.
Сесіл Каррі,

115

Я прийшов сюди попереджувально, очікуючи, що це буде проблемою, але для мене працює наступна "багаторядкова" команда для читабельності:

Gitlab Runner: Shell Runner версія 1.11.0 / версія Gitlab: 8.17.2

myjob:
stage: deploy
script:
  # Single line command
  - az component update --add sql

  # Multi-line command
  - az sql server create -n ${variable} -g ${variable} -l ${variable}
    --administrator-login ${variable} --administrator-login-password ${variable}

2
У чому тут фокус? Ви відступили другий рядок до того ж рівня, що і перший рядок?
Віктор Граці,

6
@ victor-grazi Як я розумію: у звичайному YAML (скаляр простого потоку), екрани захисту (наприклад, новий рядок \n) нічого не роблять, а пробіл проігнорується - схоже, Gitlab YAML аналізує блоки сценаріїв таким чином. Про відступ: YAML spec пише, In YAML block styles, structure is determined by indentationі тому другий рядок відступає стільки, скільки потрібно для специфікації YAML (один пробіл відносно батьківського відступу), і ще один для читабельності (що технічно зайве, але красивіше).
PotatoFarmer

Працює як шарм. Також працює з усіма параметрами в новому рядку
bodolsog

26

Ви можете використовувати будь-які багаторядкові сценарії / команди через функцію yaml literal_block та anchors. Приклад:

.build: &build |
    echo -e "\n$hl🛠 Building $green$build_path/$build_assets_dir/*.js $nl\n"
    echo -e "javascript-obfuscator $build_path/$build_assets_dir/*.js"
[...]

build:master: 
  stage: build
  script:
    - *rsync
    - *build
[...]

Дякуємо за поділ - ця вдосконалена функціональність буде особливо корисною для читабельності завдання / можливості повторного використання фрагментів коду у всьому рецепті.
PotatoFarmer

5
Це чудовий приклад, але було б зрозуміліше, якщо ви визначите .rsync
Віктор Граці

13

Команда wp config create була досить вибагливою ... від .gitlab-ci ...

build:
  stage: build
  script:
    - echo "Building the app"
    - |
        wp config create --dbname=$vardb --dbhost=$varhost --dbuser=$varusr --dbpass=$varpas --extra-php <<PHP
            define( 'WP_DEBUG', false );
            define( 'FS_METHOD', 'direct' );
            define( 'WP_POST_REVISIONS', 5 );
            define( 'AUTOSAVE_INTERVAL', 600 );
        PHP
    - scp ./wp-config.php continued...
  allow_failure: true

4

Це працює для мене в Тревісі CI

before_install:
  - set -e
  - |
    echo "<?xml version=\"1.0\" encoding=\"UTF-8\"?>
    <settings xmlns=\"http://maven.apache.org/SETTINGS/1.0.0\"
              xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"
              xsi:schemaLocation=\"http://maven.apache.org/SETTINGS/1.0.0
                                   http://maven.apache.org/xsd/settings-1.0.0.xsd\">
      <servers>
        <server>
          <id>github</id>
          <username>${GITHUB_USERNAME}</username>
          <password>${GITHUB_PASSWORD}</password>
        </server>
      </servers>
    </settings>
    " >  ${HOME}/.m2/settings.xml

Тут дві змінні env ( ${GITHUB_USERNAME}і ${GITHUB_PASSWORD}) також будуть інтерпольовані


0

Цей формат буде працювати. використовувати простий (без лапок) скаляр у YAML. Наприклад, скрипт, який використовується для ініціалізації серверного сервера тераформ

  before_script:
    - cd ${TF_ROOT}
    - terraform init -backend-config="address=${GITLAB_TF_ADDRESS}"
      -backend-config="lock_address=${GITLAB_TF_ADDRESS}/lock"
      -backend-config="unlock_address=${GITLAB_TF_ADDRESS}/lock"
      -backend-config="username=${GITLAB_USER_LOGIN}" -backend-config="password=${GITLAB_ACCESS_TOKEN}"
      -backend-config="lock_method=POST" -backend-config="unlock_method=DELETE"
      -backend-config="retry_wait_min=5"
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.