Comments 25
Какой же этот Дженкинс убогий. Понимаю, что из опенсорс мира мало что сравнится с ним, но вы на скриншоты посмотрите! Да скриптовый пайплайны это круто, но это невозможно отлаживать. Доколе?!
Взрослые фанаты опенсорса рекомендуют всякие плагины типа Blue Ocean для сокрытия убогости интерфейса и общей архаичности Hudson/Jenkins.
BlueOcean тормозит, и он предназначен только для отображения пайпалайнов. Все административные задачи выполняются в классическом UI.
А ещё, если какая-то ошибка произошла в скрипте, который не находится внутри блока stage — в BlueOcean её не увидишь. Только в классическом интерфейсе, где-то в самом конце.
Так вам шашечки или ехать? ( c )
Можно пример не убогого CI/CD?
Можно пример не убогого CI/CD?
Может выглядит не очень, но пашет как бык. Мы его используем с первой версии, когда он ещё hudson назывался. За 15 лет смотрели на много альтернатив. Остальные кроме внешнего вида функционального превосходства не дают.
Обычно проблема отсутствия отладки частично решается тем, что в скриптовых пайплайнах оставляют только переменные окружения (те же credentials, к примеру) и пару тройку вызовов скриптов.
Эти скрипты должны одинаково хорошо выполняться как в Jenkins/TeamCity/etc, так и на локальной машине. Желательно писать скрипты, поддающиеся отладке (Gradle/Nuke/etc).
Иногда скрипты дробят на части и каждую часть вызывают в отдельном стейдже пайплайна Jenkins. Как мне кажется, это совсем не обязательно. Я вот, например, не стесняюсь вызывать один Target/Task/etc. В зависимостях этого таргета прописываю все, что нужно выполнить в этом пайплайне (сборку, тестирование с покрытием, анализ результатов в SonarQube и т.д.). Лог все равно останется структурированным, т.к. скрипт уже сам об этом позаботится.
Эти скрипты должны одинаково хорошо выполняться как в Jenkins/TeamCity/etc, так и на локальной машине. Желательно писать скрипты, поддающиеся отладке (Gradle/Nuke/etc).
Иногда скрипты дробят на части и каждую часть вызывают в отдельном стейдже пайплайна Jenkins. Как мне кажется, это совсем не обязательно. Я вот, например, не стесняюсь вызывать один Target/Task/etc. В зависимостях этого таргета прописываю все, что нужно выполнить в этом пайплайне (сборку, тестирование с покрытием, анализ результатов в SonarQube и т.д.). Лог все равно останется структурированным, т.к. скрипт уже сам об этом позаботится.
И проблема странная, и решение тоже ;)
Управлять системой через глобальные переменные забавно, но через файлик (например) проще, нагляднее, поддается отладке. Я бы ещё и через SCM делал бы; автоматически получил бы нормальное логирование: кто менял параметры, когда, с какой целью.
Изначально проблема возникла от того, что людям «не от автоматизации» понадобилось редактировать набор через какой-то удобный интерфейс. Я ничего лучше не придумал, чем сделать через Jenkins. Тут и интерфейс знакомый, и нужно просто «потыкать мышкой». Так что
Я бы ещё и через SCM делал бы; автоматически получил бы нормальное логирование: кто менял параметры, когда, с какой цельюздесь не получилось бы так просто.
При таком подходе получается, что все задачи видят все параметры. И скорее всего потребовалось прописать много разрешений для выполнения кода groovy для доступа к объектам hudson. А Вы рассматривали как вариант запустить downstream задачу с помощью build step из upstream задачи и передать массив параметров?
А не будет гонки данных, когда несколько задач запускаются одновременно с разными параметрами?
И чем плох стандартный способ передачи?
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 имеет штатный механизм агентов
Sign up to leave a comment.
Простой способ редактирования, хранения и передачи параметров между job'ами Jenkins