K
Без пайпа ничего непонятно. А вообще если нужно выполнение. stage по условию используйте when
Используем разные ноды под каждый таск, таск1 и таск2 сделаны для параллельного исполнения
Size: a a a
2021 March 27
D
Alex Demidov
Jenkins :) но он не простой.
пайплайн не простой, а классик очень даже
AD
понял, все мои поиски в гугле к нему и приводили. Ну тогда буду пробовать. Спасибо!
Вариантов тут тьма. Кроме Jenkins есть Gitlab CI, Github Actions, Azure Pipelines и еще пачка всяких CI. Выбирать по вкусу
D
а вообще как гитхуки есть .gitlab-ci.yml
K
Используем разные ноды под каждый таск, таск1 и таск2 сделаны для параллельного исполнения
tasks=[:],
task[Ubuntu] { node (Ubuntu){...}},
tasks.push(task[Ubuntu)
task[Bsd] {node (Bsd){...}},
tasks.push(task[Bsd)
task[Burn cd]{...}
parallel tasks
task[Ubuntu] { node (Ubuntu){...}},
tasks.push(task[Ubuntu)
task[Bsd] {node (Bsd){...}},
tasks.push(task[Bsd)
task[Burn cd]{...}
parallel tasks
AP
Alex Demidov
Jenkins :) но он не простой.
У него есть какие-то преимущества по сравнению с Gitlab?
AP
Alex Demidov
Вариантов тут тьма. Кроме Jenkins есть Gitlab CI, Github Actions, Azure Pipelines и еще пачка всяких CI. Выбирать по вкусу
CircleCI, если устроит облачное.
e
Alexander Prokopyev
У него есть какие-то преимущества по сравнению с Gitlab?
плагины
KM
tasks=[:],
task[Ubuntu] { node (Ubuntu){...}},
tasks.push(task[Ubuntu)
task[Bsd] {node (Bsd){...}},
tasks.push(task[Bsd)
task[Burn cd]{...}
parallel tasks
task[Ubuntu] { node (Ubuntu){...}},
tasks.push(task[Ubuntu)
task[Bsd] {node (Bsd){...}},
tasks.push(task[Bsd)
task[Burn cd]{...}
parallel tasks
Используйте декларативный подход, там будет проще
AD
Alexander Prokopyev
У него есть какие-то преимущества по сравнению с Gitlab?
оно легаси и есть на каждом углу ;)
AD
Alexander Prokopyev
CircleCI, если устроит облачное.
при выборе облачного решения надо помнить о судьбе TravisCI
K
Используйте декларативный подход, там будет проще
Мешать же не комильфо
VC
Привет. Как реализовать автоматически загрузку внесённых изменений с Git в docker-контейнер? Суть такова, я например изменяю html-страницу, пушу её на git, оттуда нужно как-то её залить в мой контейнер с apache на vps. Подскажите пожалуйста, как это можно максимально просто сделать в целях обучения?
Относительно просто сделать билд нового образа, удаление староого контейнера и создание нового уже из нового образа. Вносить изменения в существующий контейнер без его остановки гораздо сложнее и противоречит идеям докера
AP
Alex Demidov
оно легаси и есть на каждом углу ;)
Пишут, что слишком много ручной работы на старте по настройке Jenkins. Типа как 1Це прошлых лет по сравнению с облачными типа Эльба Премиум, когда все и сразу. Теоретически для какой-то части DevOps-ов вероятно это может быть и плюс, создающий им рабочие места. Но и без того есть сотни DevOps тулзов, которые надо изучать и изучать.
AD
Alexander Prokopyev
Пишут, что слишком много ручной работы на старте по настройке Jenkins. Типа как 1Це прошлых лет по сравнению с облачными типа Эльба Премиум, когда все и сразу. Теоретически для какой-то части DevOps-ов вероятно это может быть и плюс, создающий им рабочие места. Но и без того есть сотни DevOps тулзов, которые надо изучать и изучать.
Примитивный Jenkinsfile для пересборки docker займет один-два экрана.
KM
Мешать же не комильфо
Так и не мешайте
pipeline {
agent none
stages {
stage('Parallel run') {
parallel {
stage('Run On Windows') {
agent {
label "windows"
}
steps {
bat "run.bat"
}
}
stage('Run On Linux') {
agent {
label "linux"
}
steps {
sh "run.sh"
}
}
}
stage('Run next'){
steps{
'Run'
}
}
}
}
}
Вот весь пайп. Две задаче в паралели выполняются, если обе будут успешные, то выполнится третий стейдж
pipeline {
agent none
stages {
stage('Parallel run') {
parallel {
stage('Run On Windows') {
agent {
label "windows"
}
steps {
bat "run.bat"
}
}
stage('Run On Linux') {
agent {
label "linux"
}
steps {
sh "run.sh"
}
}
}
stage('Run next'){
steps{
'Run'
}
}
}
}
}
Вот весь пайп. Две задаче в паралели выполняются, если обе будут успешные, то выполнится третий стейдж
K
Так и не мешайте
pipeline {
agent none
stages {
stage('Parallel run') {
parallel {
stage('Run On Windows') {
agent {
label "windows"
}
steps {
bat "run.bat"
}
}
stage('Run On Linux') {
agent {
label "linux"
}
steps {
sh "run.sh"
}
}
}
stage('Run next'){
steps{
'Run'
}
}
}
}
}
Вот весь пайп. Две задаче в паралели выполняются, если обе будут успешные, то выполнится третий стейдж
pipeline {
agent none
stages {
stage('Parallel run') {
parallel {
stage('Run On Windows') {
agent {
label "windows"
}
steps {
bat "run.bat"
}
}
stage('Run On Linux') {
agent {
label "linux"
}
steps {
sh "run.sh"
}
}
}
stage('Run next'){
steps{
'Run'
}
}
}
}
}
Вот весь пайп. Две задаче в паралели выполняются, если обе будут успешные, то выполнится третий стейдж
Спасибо
AP
Alex Demidov
при выборе облачного решения надо помнить о судьбе TravisCI
Подорожало? Цирукль предлагают и в self hosting, но лицуха от 30 юзеров, явно недешевая.
AD
Alexander Prokopyev
Подорожало? Цирукль предлагают и в self hosting, но лицуха от 30 юзеров, явно недешевая.
отменили халявные тарифные планы
VC
Alexander Prokopyev
У него есть какие-то преимущества по сравнению с Gitlab?
Если ничего в Гитлабе не менялось в этом плане, то в Дженкинсе гораздо проще создавать сценарии для нескольких репозиториев, типа жмём “деплой” и: билдится фронт пайплайном из своей репы, билдится бэк пайплайном из своей репы, сервер полностью переводится в “извините, идут технические работы”, деплоится фронт и бэк, запускаются смок-тесты из пайплайна в свем репозитории. Если успещно то сервер переводится в рабочий режим. если не то пайплайн деплоя предущих билдов с ручным подтверждением