DB
подготовьте контекст вне билда
Size: a a a
2020 August 03
DB
Тянешь все зависимости билда из jenkins. А затем собираешь образы. Нет смысла из образа пулить репы
this
С
подготовьте контекст вне билда
+
DS
Я именно этого и пытаюсь избежать через docker multistage build. Так бы я вообще не парился бы с подсовыванием ключа. Дело в том что подсунуть его первой стадии биулда можно только через ARG. Я не нашел других методов вменяемых
Это даже локально неудобно.
Легче выполнить некотрый pre-build.sh или git submodule init && git submodule updatet.
Чем создавать SSH_PRIVATE_KEY с ключом и пихать его в build-arg
Легче выполнить некотрый pre-build.sh или git submodule init && git submodule updatet.
Чем создавать SSH_PRIVATE_KEY с ключом и пихать его в build-arg
DS
Ну и со слоями накосячишь, и ключ окажется в образе в итоге, лишний риск на ровном месте
PN
Это даже локально неудобно.
Легче выполнить некотрый pre-build.sh или git submodule init && git submodule updatet.
Чем создавать SSH_PRIVATE_KEY с ключом и пихать его в build-arg
Легче выполнить некотрый pre-build.sh или git submodule init && git submodule updatet.
Чем создавать SSH_PRIVATE_KEY с ключом и пихать его в build-arg
Мне хотелось бы иметь универсальный докерфайл который можно собрать и локально и запушить результат в реджистри и тоже самое делать дженкинсом. Башнянку я отладил, а с дженкинсом приключения. Тут еще масса вторичных условий который обойти нельзя: смое простое - код докерфайла с обвязкой и конфигами в одном гите, а код приложения в другом гите. Понятно что сразу нужно было писать на дженкинсе, но исторически сначала отладился баш-метод. Тут ситуация когда нельзя "правильно" и канонично jenkinsfile + dockerfile, к сожалению (
KI
в общем, всё получилось с помощью плагина Azure Container Agents и небольших плясок с передачей переменных окружения. Если кому-то нужна будет помощь в конфигурации, обращайтесь :)
DS
Мне хотелось бы иметь универсальный докерфайл который можно собрать и локально и запушить результат в реджистри и тоже самое делать дженкинсом. Башнянку я отладил, а с дженкинсом приключения. Тут еще масса вторичных условий который обойти нельзя: смое простое - код докерфайла с обвязкой и конфигами в одном гите, а код приложения в другом гите. Понятно что сразу нужно было писать на дженкинсе, но исторически сначала отладился баш-метод. Тут ситуация когда нельзя "правильно" и канонично jenkinsfile + dockerfile, к сожалению (
вытаскиваешь дичь с ssh ключами из dockerfile, делаешь pre-build.sh который готовит контекст перед билдом. pre-build.sh вызываешь из jenkins. Вот у тебя и локально и из jenkins сборки не будут отличаться. И получаешь универсальный билд
PN
вытаскиваешь дичь с ssh ключами из dockerfile, делаешь pre-build.sh который готовит контекст перед билдом. pre-build.sh вызываешь из jenkins. Вот у тебя и локально и из jenkins сборки не будут отличаться. И получаешь универсальный билд
Я понял идею, спасибо!
VS
Гайз, а можно как-то полученное в джобе значение, обернуть в *
Чтобы при последующих принтах это значение уже не печаталось в открытом виде? Также как это работает для withCredentials
Чтобы при последующих принтах это значение уже не печаталось в открытом виде? Также как это работает для withCredentials
AD
можно как вариант обернуть в MaskPasswordsBuildWrapper
VS
Alex Di
можно как вариант обернуть в MaskPasswordsBuildWrapper
VS
Вот прям берет и тупо распечатывает пароль в заголовке))
2020 August 04
V
в общем, всё получилось с помощью плагина Azure Container Agents и небольших плясок с передачей переменных окружения. Если кому-то нужна будет помощь в конфигурации, обращайтесь :)
Я рад, красавчик )
II
а пайплайн никак нельзя попросить при печати стектрейсов исключений, ограничивать оные только строчками пайплайна и shared libraries? дабы вместо ужаса со скриншота иметь лаконичное
org.jenkinsci.plugins.workflow.steps.MissingContextVariableException: ...
at WorkflowScript.run(WorkflowScript:1)
d
Добрый день. Подскажите, знатоки Дженкинса.
Есть большой репозиторий, который хранит много независимых друг от друга исходников программ. Хранение программ строго организовано: у каждой своя папка с исходниками и скриптом сборки.
Ветка мастер хранит только рабочие версии исходников программ. Я создаю свою локальную ветку от ветки мастер и добавляю в 2 разных программы функционал. Далее мержу эту ветку в ветку develop, которая хранит разрабатываемые версии программ. При мерже обязательно создаю мерж-коммит. Возможно ли настроить Дженкинс так, чтобы в момент создания мерж-коммита он собрал только те программы, которые я изменил в своей ветке?
Есть большой репозиторий, который хранит много независимых друг от друга исходников программ. Хранение программ строго организовано: у каждой своя папка с исходниками и скриптом сборки.
Ветка мастер хранит только рабочие версии исходников программ. Я создаю свою локальную ветку от ветки мастер и добавляю в 2 разных программы функционал. Далее мержу эту ветку в ветку develop, которая хранит разрабатываемые версии программ. При мерже обязательно создаю мерж-коммит. Возможно ли настроить Дженкинс так, чтобы в момент создания мерж-коммита он собрал только те программы, которые я изменил в своей ветке?
DB
git diff HEAD^ --name-only --diff-filter=AMd
git diff HEAD^ --name-only --diff-filter=AMСпасибо. Я так понимаю, это ответ: "Да, возможно"?
DB
в дженкинсе всё можно. вопрос в ресурсах
d
в дженкинсе всё можно. вопрос в ресурсах
Что за ресурсы?