tag - ¿Cómo usamos la palabra clave ''variables'' en gitlab-ci.yml?

gitlab ci triggers

Question

Estoy tratando de hacer uso de las variables: palabra clave documentada en la documentación de Gitlab CI aquí:

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

variables

Esta característica requiere gitlab-runner con una versión igual o superior a 0.5.0.

GitLab CI le permite agregar a .gitlab-ci.yml las variables que se establecen en el entorno de compilación. Las variables se almacenan en el repositorio y están destinadas a almacenar la configuración del proyecto no sensible, es decir. RAILS_ENV o DATABASE_URL.

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

Estas variables se pueden usar posteriormente en todos los comandos y scripts ejecutados.

Las variables definidas por YAML también se configuran para todos los contenedores de servicios creados, lo que permite ajustarlos.

Cuando intento usarlo, mis compilaciones no se ejecutan en ninguna etapa y se marcan con éxito de todos modos, una buena señal de un mal YAML. Pegué el contenido de gitlab-ci.yml en la herramienta LINT en el área de configuración y el error de salida es:

Estado : la sintaxis es incorrecta

Error : trabajo de variables: parámetro desconocido PACKAGE_NAME

Estoy usando mi sintaxis YAML igual que los documentos, sin embargo, no funcionará. No puedo encontrar ningún error abierto relacionado con esto. A continuación se muestran mis versiones actuales y una versión desinfectada de mi gitlab-ci.yml.

Versión de Gitlab : 7.13.2 Omnibus

Versión 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

Pregunta:

¿Cómo uso este valor correctamente?

Información adicional:

Eliminar esta sección del archivo YAML hace que todo funcione, por lo que el resto del archivo está funcionando correctamente. (Por supuesto, las variables indefinidas conducen a errores de script ...)

Incluso solo reducir las variables para realizar pruebas a solo PACKAGE_NAME provoca el mismo salto.

Answer 1

La respuesta original ya no es correcta.

La documentación original ahora está en pie, ahora también hay más formas. Las variables se pueden crear desde la GUI, API o definiéndose en .gitlab-ci.yml también.

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

Answer 2

Si bien está en la documentación, no creo que las variables se incluyeran en la última versión de gitlab (7.13). La funcionalidad para leer las variables de los archivos yaml fue incorporada por un confirmado por ayufan hace 9 días.

Mirando el analizador en la rama estable de 7.13 , puede ver que su contribución no tuvo éxito. Asumiendo que está en la versión 7.13 o anterior, me temo que no tenemos suerte. Como está en master, estoy bastante seguro de que lo veremos en la próxima versión. Hasta entonces, podríamos hacer un parche de mono, hacer un git pull si estás usando la fuente directamente, o simplemente confiar en las variables del proyecto hasta la próxima versión.