Gitlab CI variables — переменные, которые можно задать в интерфейсе Gitlab. Как переменная может задаваться, например, пароль доступа к какому-либо сервису.
Gitlab CI variables — переменные в .gitlab-ci.yml
Тесты в gitlab задаются в файле .gitlab-ci.yml, который размещается в корне репозитория.
Приведенный ниже фрагмент файла с тестами является логическим продолжением файла, рассмотренного в первой статье по gitlab тестам.
Сценарий разделен на несколько stage-ей. Обычно они включают test и deploy. Количество jobs на один stage при этом не ограничено. Если, например, для stage: deploy существует два блока с командами — выполняться они будут параллельно.
Ниже фрагмент из сценария, который можно использовать для проекта. Job для s3 будет выполняться при коммите в master, job pages — при коммите в любую другую ветку.
Для pages подготавливаются артефакты, сохраняющиеся в каталоге public на сервере. При коммите в master изменения отправляются в корзину в хранилище Amazon.
s3: image: python stage: deploy script: - pip install awscli - aws cp ./ s3://bucket/ --recursive only: - master pages: stage: deploy image: alpine script: - mkdir -p ./public && cp ./*.* ./public/ artifacts: paths: - public except: - master
Для того, чтобы работать с S3 и часто любым другим сторонним сервисом требуется авторизация. В Amazon она реализуется за счет ключей доступа.
Это наборы символов, которые сохраняются на локальном компьютере. Если использовать хранилище будут разные люди возникает необходимость указания ключей.
Указать их можно в сценарии, однако это небезопасно (особенно если репозиторий публичный).
variables: AWS_ACCESS_KEY_ID: "1111111111111111111" AWS_SECRET_ACCESS_KEY: “222222222222222”
Gitlab позволяет выйти из ситуации задав переменные.
Как задать переменные в Gitlab
В данном случае требуется две переменные:
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
Переменные задаются для репозитория, в меню слева Settings -> CI/CD -> Enviroment Variables
Переменные можно скрыть. Так стоит сделать для ключей доступа и паролей.
Переменные применяются к окружению за счет runner-а. Они заданы для проекта и скрыты, при этом будут считываться также как считываются после выполнения aws configure
Фрагмент .gitlab-ci.yml после добавления окружения для каждой задачи будет выглядеть так
s3: enviroment: production image: python stage: deploy script: - pip install awscli - aws cp ./ s3://yourbucket/ --recursive only: - master when: manual pages: image: alpine:latest enviroment: staging state: deploy image: alpine script: - mkdir -p ./public && cp ./*.* ./public/ artifacts: paths: - public except: - master
Пример в статье взят из документации Gitlab.
Gitlab CI variables нужно использовать во всех проектах, в которых фигурируют какие-то переменные, особенно если значением переменных являются реквизиты доступа к компонентам системы.
Читайте про Gitlab runner и запуске тестов в Docker контейнерах.