How do we use the 'variables' keyword in gitlab-ci.yml?

Question

I am trying to make use of the variables: keyword documented in the Gitlab CI Documentation here:

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

variables

This feature requires gitlab-runner with version equal or greater than 0.5.0.

GitLab CI allows you to add to .gitlab-ci.yml variables that are set in build environment. The variables are stored in repository and are meant to store non-sensitive project configuration, ie. RAILS_ENV or DATABASE_URL.

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

These variables can be later used in all executed commands and scripts.

The YAML-defined variables are also set to all created service containers, thus allowing to fine tune them.

When I attempt to use it, my builds do not run any stages and are marked successful anyway, a good sign of bad YAML. I pasted my gitlab-ci.yml contents into the LINT tool in the settings area and the output error is:

Status: syntax is incorrect

Error: variables job: unknown parameter PACKAGE_NAME

I'm using my YAML syntax the same as the docs, however it will not work. I'm unable to find any open bugs related to this. Below are my current versions and a sanitized version of my gitlab-ci.yml.

Gitlab Version: 7.13.2 Omnibus

Gitlab Runner Version: 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:

How do I use this value properly?

Additional Info:

Removing this section from the YAML file causes everything to work so the rest of the file is in working order. (Of course undefined variables lead to script errors...)

Even just reducing the variables for testing down to just PACKAGE_NAME causes the same break.

Answer 1

The original answer is no longer correct.

The original documentation now stands, Now there are more ways as well. Variables can be created from the GUI, API, or by being defined in the .gitlab-ci.yml as well.

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

Answer 2

While it is in the documentation, I do not believe that variables were included in the latest version of gitlab (7.13). The functionality to read variables out of the yaml files was brought in by a commit by ayufan 9 days ago.

Looking at the parser on the 7.13 stable branch, you can see that his contribution did not make it in. So assuming you're on 7.13 or earlier, I'm afraid we are out of luck. Since it is on master, I am fairly certain that we'll see it in the next release. Until then, we could either monkey patch, do a git pull if you're using the source directly, or just rely on the project variables until the next release.