web-dev-qa-db-fra.com

Comment utilisons-nous le mot-clé 'variables' dans gitlab-ci.yml?

J'essaie d'utiliser le variables: mot clé documenté dans la documentation de Gitlab CI ici:

FROM: https://docs.gitlab.com/ce/ci/yaml/README.html

les variables

Cette fonctionnalité nécessite gitlab-runner avec une version égale ou supérieure à 0.5.0.

GitLab CI vous permet d'ajouter aux variables .gitlab-ci.yml définies dans l'environnement de génération. Les variables sont stockées dans le référentiel et sont destinées à stocker la configuration de projet non sensible, c'est-à-dire. Rails_ENV ou DATABASE_URL.

variables:   
  DATABASE_URL: "postgres://postgres@postgres/my_database"

Ces variables peuvent être utilisées ultérieurement dans toutes les commandes et tous les scripts exécutés.

Les variables définies par YAML sont également définies pour tous les conteneurs de services créés, ce qui permet de les affiner.

Lorsque j'essaye de l'utiliser, mes builds n'exécutent aucune étape et sont quand même marqués comme réussis, un bon signe de mauvais YAML. J'ai collé mon contenu gitlab-ci.yml dans l'outil LINT dans la zone des paramètres et l'erreur de sortie est:

Statut : la syntaxe est incorrecte

Erreur : tâche de variables: paramètre inconnu PACKAGE_NAME

J'utilise ma syntaxe YAML de la même manière que les documents, mais cela ne fonctionnera pas. Je ne trouve aucun bogue ouvert lié à cela. Voici mes versions actuelles et une version aseptisée de mon gitlab-ci.yml.

Version Gitlab : 7.13.2 Omnibus

Version de Gitlab Runner : 0.5.2

gitlab-ci.yml (Sanitized) 

types:
  - test
  - build

variables:
  PACKAGE_NAME: "awesome-Django-app"
  PACKAGE_SUMMARY: "Awesome webapp backend."
  MAJOR_RELEASE: "1"
  MINOR_RELEASE: "0"
  PATCH_LEVEL: "0dev"
  DEV_DB_URL: "db"
  DEV_SERVER: "pydev.example.com"
  PROD_SERVER: "pyprod.example.com"
  TEST_SERVER: "pytest.example.com"

envtest:
  type: test
  script:
  - ". ./testbuild.sh"
  tags:
  - python2.7
  - postgres
  - linux
  except:
  - tags

buildrpm:
  type: build
  script:
  - mkdir -p ~/rpmbuild/SOURCES
  - mkdir -p ~/rpmbuild/SPECS
  - mkdir -p ~/tarbuild/$PACKAGE_NAME-$MAJOR_RELEASE.$MINOR_RELEASE.$PATCH_LEVEL
  - cp $PACKAGE_NAME.spec ~/rpmbuild/SPECS/.
  - cp -r * ~/tarbuild/$PACKAGE_NAME-$MAJOR_RELEASE.$MINOR_RELEASE.$PATCH_LEVEL/.
  - cd ~/tarbuild
  - tar -zcf ~/rpmbuild/SOURCES/$PACKAGE_NAME-$MAJOR_RELEASE.$MINOR_RELEASE.$PATCH_LEVEL.tar.gz *
  - cd ~
  - rm -Rf ~/tarbuild
  - rpmlint -i ~/rpmbuild/SPECS/$PACKAGE_NAME.spec
  - echo $CI_BUILD_ID
  - 'rpmbuild -ba ~/rpmbuild/SPECS/$PACKAGE_NAME.spec \
                    --define="_build_number $CI_BUILD_ID" \
                    --define="_python_version_min 2.7" \
                    --define="_version $MAJOR_RELEASE.$MINOR_RELEASE.$PATCH_LEVEL" \
                    --define="_package_name $PACKAGE_NAME" \
                    --define="_summary $SUMMARY"'
  - scp rpmbuild/RPMS/noarch/$PACKAGE_NAME-$MAJOR_RELEASE.$MINOR_RELEASE.$PATCH_LEVEL-$CI_BUILD_ID.noarch.rpm $DEV_SERVER:~/.
  tags:
  - python2.7
  - postgres
  - linux
  - rpm
  except:
  - tags

Question:

Comment utiliser correctement cette valeur?

Informations supplémentaires:

La suppression de cette section du fichier YAML fait que tout fonctionne donc le reste du fichier est en ordre de marche. (Bien sûr, des variables non définies entraînent des erreurs de script ...)

Même la simple réduction des variables à tester à seulement PACKAGE_NAME provoque la même interruption.

variablesgitlabgitlab-ci
24
Routhinator

La réponse originale n'est plus correcte.

La documentation d'origine existe maintenant, il y a maintenant plus de moyens. Les variables peuvent être créées à partir de l'interface graphique, de l'API ou en étant définies dans le .gitlab-ci.yml ainsi que.

https://docs.gitlab.com/ce/ci/variables/README.html

11
Routhinator

Bien que cela se trouve dans la documentation, je ne pense pas que les variables aient été incluses dans la dernière version de gitlab (7.13). La fonctionnalité de lecture des variables des fichiers yaml a été apportée par --- commit by ayufan il y a 9 jours.

En regardant l'analyseur de la branche stable de 7.1 , vous pouvez voir que sa contribution n'a pas réussi. Donc, en supposant que vous êtes sur 7.13 ou plus tôt, je crains que nous n'ayons pas de chance. Puisqu'il est sur master, je suis assez certain que nous le verrons dans la prochaine version. Jusque-là, nous pourrions soit corriger le singe, faire un pull git si vous utilisez directement la source, ou simplement compter sur les variables du projet jusqu'à la prochaine version.

8
Don Mayo