Я пытаюсь создать в Jenkins задание, в котором в качестве триггера сборки используется «токен аутентификации» (поэтому он будет выполнять сборку при помощи git push).Я определяю все, используя Job DSL, т.е. без какой-либо ручной настройки каких-либо заданий.
Токен аутентификации определен в Jenkins как учетные данные, поскольку я не хочу, чтобы этот токен был жестко запрограммирован и проверен в SCM.
Работает следующее: он определяет загрузочное задание , которое, в свою очередь, определяет задание seed с учетными данными, привязанными к переменной среды;Затем задание seed определяет фактическое задание на сборку (которое является важным - которое я хочу иметь возможность запускать с использованием токена).
bootstrap.groovy:
/*
* Create the seed job, and bind the credential to it, for use downstream
*/
def seed_dsl = readFileFromWorkspace('./jobs/seed.groovy')
job('seed')
{
wrappers {
credentialsBinding {
string ('AUTH_TOKEN','my-trigger-token')
}
}
steps {
dsl {
text(seed_dsl)
}
}
}
/* Queue the job */
queue('seed')
seed.groovy:
/*
* Create the build job, and associate the authentication token with it
*/
job('My Useful Build Job') {
authenticationToken(AUTH_TOKEN)
steps {
shell ('echo Do something useful like build my app here')
}
}
Но теперь у меня есть цепочка 3 рабочих мест: начальная загрузка > seed > My Use Build Job .Это имхо немного неприятно пахнет - это громоздко, загромождает Дженкинса, и его трудно объяснить.
Можно ли это упростить, чтобы удалить промежуточное задание - т.е. я хочу иметь возможность создать задание с токеном аутентификации, определенным как учетные данные, но в два этапа: seed > Моя полезная работа по сборке