Chaîne YAML multiligne pour GitLab CI (.gitlab-ci.yml)

Question

Je suis en train d'essayer d'écrire un fichier gitlab-ci.yml qui utilise une chaîne multiligne pour la commande. Cependant, il semble que cela ne soit pas interprété. J'ai essayé à la fois - | et - > avec des résultats identiques.

étapes:
  - mystage

Construction:
  stage: mystage
  script:
    - |
        echo -e "
            echo 'salut';
            echo 'au revoir';
        "

Lorsqu'il essaie de s'exécuter, il ne montre que echo -e ' comme script à exécuter, et non toute la chaîne multiligne. Cela me pose des problèmes.

Quelle serait la syntaxe correcte pour écrire quelque chose comme ça?

Answer 1

Je suis venu ici préventivement en m'attendant à ce que ce soit un problème mais la commande "multi-ligne" suivante pour la lisibilité fonctionne pour moi:

Gitlab Runner: Version du coureur Shell 1.11.0 / Version de Gitlab: 8.17.2

myjob:
stage: deploy
script:
  # Commande en une seule ligne
  - az component update --add sql

  # Commande multi-ligne
  - az sql server create -n ${variable} -g ${variable} -l ${variable}
    --administrator-login ${variable} --administrator-login-password ${variable}

Answer 2

TL;DR; Vous voulez utiliser un scalaire YAML multi-ligne (pour la lisibilité) qui est chargé comme une seule ligne de chaîne qui peut être émise en tant que commande par Gitlab-CI. Pour ce faire, utilisez un scalaire standard (sans guillemets) en YAML qui est réparti sur plusieurs lignes :

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

Sachez qu'il existe certaines restrictions imposées par YAML sur de tels scalaires. Ce que vous devez absolument savoir, c'est que chaque ligne suivante est indentée d'au moins une position de plus que echo -e (qui est indenté de deux positions par rapport à son nœud de collection, qui n'est pas du tout indenté), et que chaque nouvelle ligne est remplacée par un espace lors du chargement (donc vous devez faire un peu attention à l'endroit où mettre les sauts de ligne).

---

Il y a plusieurs idées fausses dans votre publication, qui vous amènent à poser la mauvaise question.

Il n'y a pas de tel chose comme une chaîne YAML multi-ligne. YAML a des scalaires et certains de ces scalaires peuvent être chargés par un programme en tant que chaînes, tandis que d'autres seront chargés en tant qu'entiers, flottants, etc.

Vous êtes évidemment intéressé par des nœuds scalaires qui sont chargés en tant que chaîne, puisque cette chaîne peut ensuite être interprétée comme une commande en ligne. Mais vous ne voulez pas avoir une commande en ligne multi-ligne (c'est-à-dire avec des sauts de ligne intégrés), puisque les scripts multi-lignes ne sont pas pris en charge dans Gitlab CI (comme l'a indiqué @Jordan).

Pour la lisibilité, vous voulez utiliser la capacité standard de YAML à charger des scalaires multi-lignes en tant que chaîne sur une seule ligne.

Si vous ne vous souciez pas de la lisibilité, vous pourriez utiliser :

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

et puisque votre scalaire n'est pas entre guillemets (c'est-à-dire qu'il commence par echo), vous n'avez pas besoin de faire quelque chose de spécial en YAML pour les anti-slashs ou les guillemets.

Le résultat du script est le même (afficher une ligne vide, afficher echo 'hi'; sur une ligne indentée quatre espaces, afficher echo 'bye'; sur une ligne indentée quatre espaces.)

Si vous voulez utiliser l'entrée multi-ligne pour la lisibilité, qui est chargée sur une seule ligne, il existe essentiellement deux options : utilisez un scalaire multi-ligne standard ou utilisez un scalaire plié dans votre YAML.

scalaire multi-ligne standard

Standard signifie que le scalaire n'est pas entre guillemets, et comme pour toute chose multi-ligne en YAML, multi-ligne signifie que les lignes suivantes doivent être indentées de manière appropriée, dans ce cas plus que la ligne initiale

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

les sauts de ligne sont remplacés par des espaces donc ne faites pas :

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

car vous obtiendrez un espace visible avant bye.

Il y a quelques restrictions comme le fait que vous ne pouvez pas avoir un deux-points suivi d'un espace dans un tel scalaire (ce qui le ferait ressembler à une paire clé-valeur).

Il n'est pas nécessaire d'échapper les anti-slashs dans les scalaires standard, car vous ne pouvez échapper aucun caractère dans un scalaire standard, mais bien sûr vous pouvez inclure un anti-slash, qui se retrouvera dans la chaîne chargée depuis le YAML et peut avoir une signification pour la commande exécutée à partir de cette chaîne.

scalaire plié

Un scalaire plié est similaire à un scalaire standard en ce sens que tous les sauts de ligne sont remplacés par un espace lors du chargement :

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

Vous devez indenter les informations de commande réelle au moins autant que l'indicateur de scalaire plié (>).

Contrairement aux scalaires standard, des choses comme : n'ont pas de signification particulière. Donc si les scalaires standard échouent en lançant une erreur YAML, il est probable que des scalaires pliés similaires ne le feront pas.

Answer 3

Vous pouvez utiliser n'importe quelle script/commande multi-ligne via le yaml literal_block et la fonctionnalité des ancres. Exemple:

.build: &build |
    echo -e "\n$hl Construction de $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
[...]

Answer 4

La commande de création de configuration wp était assez capricieuse... depuis le fichier .gitlab-ci...

build:
  stage: build
  script:
    - echo "Construction de l'application"
    - |
        wp config create --dbname=$vardb --dbhost=$varhost --dbuser=$varusr --dbpass=$varpas --extra-php <

Answer 5

Cela fonctionne pour moi dans Travis CI

before_install:
  - set -e
  - |
    echo "

          github
          ${GITHUB_USERNAME}
          ${GITHUB_PASSWORD}

    " >  ${HOME}/.m2/settings.xml

Ici, deux variables d'environnement (${GITHUB_USERNAME} et ${GITHUB_PASSWORD}) seront également interpolées