Как мы используем ключевое слово 'variables' в gitlab-ci.yml?

Я пытаюсь использовать ключевое слово variables:, задокументированное в документации Gitlab CI здесь:

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

переменные

Для этой функции требуется gitlab-runner с версией, равной или большей, чем 0.5.0.

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

variables:   
  DATABASE_URL: "postgres://[email protected]/my_database"

Эти переменные могут быть позже использованы во всех выполненных командах и скрипты.

Определенные YAML переменные также устанавливаются для всех созданных сервисов контейнеры, что позволяет точно настроить их.

Когда я пытаюсь использовать его, мои сборки не запускаются на каких-либо этапах и, в любом случае, успешно отмечены, что является хорошим признаком плохого YAML. Я вложил содержимое gitlab-ci.yml в инструмент LINT в области настроек, и ошибка вывода:

Статус: неверен синтаксис

Ошибка: задание переменных: неизвестный параметр PACKAGE_NAME

Я использую синтаксис YAML так же, как и документы, однако это не сработает. Я не могу найти никаких открытых ошибок, связанных с этим. Ниже приведены мои текущие версии и санированная версия моего gitlab-ci.yml.

Версия Gitlab: 7.13.2 Omnibus

Версия Runner Gitlab: 0.5.2

gitlab-ci.yml(санированный)

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

Вопрос:

Как правильно использовать это значение?

Дополнительная информация:

Удаление этого раздела из файла YAML заставляет все работать, поэтому остальная часть файла находится в рабочем состоянии. (Конечно, переменные undefined приводят к ошибкам script...)

Даже просто уменьшение переменных для тестирования до PACKAGE_NAME вызывает тот же самый разрыв.

Ответы

Ответ 1

Оригинальный ответ больше не правильный.

Оригинальная документация теперь стоит. Теперь есть и другие способы. Переменные могут быть созданы из графического интерфейса, API или путем определения в .gitlab-ci.yml.

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

Ответ 2

Хотя в документации я не верю, что переменные были включены в последнюю версию gitlab (7.13). Функциональность для чтения переменных из файлов yaml была принесена фиксацией ayufan 9 дней назад.

Глядя на синтаксический анализатор в стабильной ветке 7.13, вы можете видеть, что его вклад не внес ее. Итак, если вы на 7.13 или раньше, я Боюсь, нам не повезло. Поскольку он находится на хозяине, я вполне уверен, что мы увидим его в следующем выпуске. До тех пор мы могли бы либо запланировать обезьяну, либо сделать git pull, если вы используете источник напрямую, или просто полагаться на переменные проекта до следующей версии.