#jenkins #kubernetes
#дженкинс #kubernetes
Вопрос:
Я пытаюсь использовать переменные среды для настройки моего агента Jenkins следующим образом:
pipeline {
environment {
TEST = "test"
}
agent {
kubernetes {
label 'kubernetes'
defaultContainer 'jnlp'
yaml """
apiVersion: v1
kind: Pod
metadata:
labels:
name: "${env.TEST}"
...
но ${env.TEST}
выходит как null
. Использование ${env.BUILD_NUMBER}
работает как ожидалось, поэтому кажется, что агент не имеет доступа к переменным среды, определенным в конвейере.
Есть ли какой-либо способ заставить это работать?
Комментарии:
1. Что касается ссылки на env.BUILD_NUMBER или другие значения, специфичные для jenkins, они загружаются в рабочий агент при передаче контекста задания. Они устанавливаются глобально для сеанса пользователя задания., следовательно, имеют определенные переменные среды, специфичные для выполняемого задания. Чтобы просмотреть все доступные env_vars из jenkins, перейдите на YOUR_JENKINS_URL/env-vars.html
Ответ №1:
Вы в принципе правы. env.VALUE используются для конкретных пользовательских переменных среды (например, если я запускаю jenkins в среде агента с установленным KUBECONFIG, согласно AMI или иным образом, это будет считаться env.KUBECONFIG). Это сбивает с толку, но обычно в библиотеке глобальные переменные среды определяются следующим образом:
env.MY_VALUE = "some value"
При обращении к env.VALUE вы проверяете фактические переменные среды пользователя. Для значений, которые вы задаете при закрытии среды, вы можете просто вызвать их с помощью MY_VALUE:
pipeline {
environment {
TEST = "test"
}
agent {
kubernetes {
label 'kubernetes'
defaultContainer 'jnlp'
yaml """
apiVersion: v1
kind: Pod
metadata:
labels:
name: "${TEST}"
...
Комментарии:
1. Я не вижу такого свойства: ТЕСТ для класса: WorkflowScript