Комментарии 25
Взрослые фанаты опенсорса рекомендуют всякие плагины типа Blue Ocean для сокрытия убогости интерфейса и общей архаичности Hudson/Jenkins.
Можно пример не убогого CI/CD?
Эти скрипты должны одинаково хорошо выполняться как в Jenkins/TeamCity/etc, так и на локальной машине. Желательно писать скрипты, поддающиеся отладке (Gradle/Nuke/etc).
Иногда скрипты дробят на части и каждую часть вызывают в отдельном стейдже пайплайна Jenkins. Как мне кажется, это совсем не обязательно. Я вот, например, не стесняюсь вызывать один Target/Task/etc. В зависимостях этого таргета прописываю все, что нужно выполнить в этом пайплайне (сборку, тестирование с покрытием, анализ результатов в SonarQube и т.д.). Лог все равно останется структурированным, т.к. скрипт уже сам об этом позаботится.
И проблема странная, и решение тоже ;)
Управлять системой через глобальные переменные забавно, но через файлик (например) проще, нагляднее, поддается отладке. Я бы ещё и через SCM делал бы; автоматически получил бы нормальное логирование: кто менял параметры, когда, с какой целью.
Я бы ещё и через SCM делал бы; автоматически получил бы нормальное логирование: кто менял параметры, когда, с какой цельюздесь не получилось бы так просто.
А вот предложенных вариантов даже не рассматривал. Они тут самую малость неприменимы.
А не будет гонки данных, когда несколько задач запускаются одновременно с разными параметрами?
И чем плох стандартный способ передачи?
manager:
build(
job: 'test_job',
parameters: [
string(name: 'param1', value: "val1"),
string(name: 'param2', value: 'val2')
]
)
job:
pipeline {
options {
parameters {
choice(name: 'param1', choices: 'val1\val2', description: 'parpam1')
string(name: 'param2', defaultValue: 'def', description: 'param2')
}
}
}
П.С. ага, вижу веткой выше уже спросили.
а эти параметры, они не меняются от сборки к сборке? И чем плохо хранить их прямо в коде пайплайна, который можно положить в репозиторий?
Из нюансов, вынужден отметить, что нажимать кнопку «Собрать» вовсе необязательно, так как перезапись глобальной переменной происходит всякий раз, когда вы выбираете один из пунктов.
Глобальная переменная перепишется без явного подтверждения? Опасная магия. «Я что-то нажала и всё пропало» (ц).
А зачем использовать глобальные переменные для этого? Как писали выше это чревато проблемами. Плюс, чтобы перезаписывать глобальные переменные, задаче нужны полные доступы в jenkins, что явно небезопасно.
Вижу несколько вариантов решения проблемы:
- использовать штатный механизм артефактов. Задача с параметрами сохраняет артефакт со всеми опциями. Задача которая запускается регулярно, используя плагин copyArtifact, копирует артефакт себе. Так как файл очень маленький, он будет копироваться моментально
- написать метод для shared libs, который достает все параметры из нужной задачи. Пример кода(код не проверял, возможно где-то ошибки):
def param = Jenkins.instance.getItemByFullName("path/to/job").builds.last().build.getActions(hudson.model.ParametersAction)[0].getParameters().find {
it.name == paramName
}
Кстати, может кто-то из читателей этой статьи сможет объяснить, почему нужно выполнять все операции (сборка дистрибутива, его тестирование и т. д.) на той же машине, где расположен Jenkins?
Нет такой необходимости, jenkins имеет штатный механизм агентов
Простой способ редактирования, хранения и передачи параметров между job'ами Jenkins