Дженкинс - беги по ночам, если новая работа сделана? - PullRequest
1 голос
/ 05 июня 2019

Прямо сейчас у меня есть два набора тестов: короткий и длинный. Короткий работает при регистрации для каждой ветви. Какой набор для запуска является параметром - SHORT или LONG. Длинный всегда работает ночью на ветке разработчика. Как я могу запустить другие ветви, чтобы построить и запустить длинный тест, если сегодня ветка была успешно построена?

Ответы [ 3 ]

2 голосов
/ 10 июня 2019

Если вы хотите запускать эти длинные тесты только ночью - я считаю, что проще всего просто продублировать задание и изменить его так, чтобы оно срабатывало ночью и добавлялись дополнительные проверки после обычного задания, т. Е. Задания после фиксациипросто сделайте короткий тест, ночной триггер сначала сделает короткий, а затем (если не будет ошибок) длинный.

Я считаю, что гораздо легче справиться, чем сложность цепочки заданий в некоторых условиях, например, оценкавремя дня, чтобы пропустить некоторые тесты.

Пример 1-го задания, которое запускается после каждого коммита

node() {
  stage('Build') {
    // Build
  }
  stage('Short Test') {
    // Short Test
  }
}

2-го задания, которое запускается ночью

node() {
  stage('Build') {
    // Build
  }
  stage('Short Test') {
    // Short Test, fail the build here when not successful
  }
  stage('Long Tests')
    // Long Test, runs only when short test successful
  }
}

Редактировать

Решение, в котором все это реализовано за одно задание, однако оно добавляет много сложности и усложняет интеграцию некоторых последующих вариантов использования, то есть различных уведомлений для ветви тестирования интеграции, отслеживания продолжительности сборки и т. Д. Я все еще нахожу его более управляемымчтобы разделить его на 2 задания.

Следующее задание должно быть настроено так, чтобы оно запускалось с помощью ловушки после фиксации и ночной таймер.Длинный тест запускается, когда

  1. последняя сборка моложе установленной (вы не хотите, чтобы она запускалась с последней ночи),
  2. последний запуск был успешным (не хочу запускатьсядлительный тест на сломанную сборку), и
  3. был вызван указанным таймером (не требуется запускать при регистрации).
def runLongTestMaxDiffMillis = 20000
def lastRunDiff = (currentBuild.getStartTimeInMillis().toInteger() - currentBuild.getPreviousBuild().getStartTimeInMillis().toInteger())

def lastBuildTooOld = (lastRunDiff > runLongTestMaxDiffMillis)
def isTriggeredByTimer = currentBuild.getBuildCauses('hudson.triggers.TimerTrigger$TimerTriggerCause')
def lastBuildSuccessful = (currentBuild.getPreviousBuild().getResult() == 'SUCCESS')

def runLongTest = (!lastBuildTooOld && isTriggeredByTimer && lastBuildSuccessful)

node() {
    if (runLongTest) {
        println 'Running long test'
    } else {
        println 'Skipping long test'
    }
}
1 голос
/ 10 июня 2019

Вы можете создать другой конвейер, который вызывает параметризованный конвейер с параметром LONG, например:

stage('long benchmark') {
    build job: 'your-benchmark-pipeline', parameters: [string(name: 'type', value: 'LONG')]
}

При настройке этого нового конвейера вы можете установить флажок Build after other projects are built в разделе Build Triggers и выбрать, какие короткие тесты должны запускаться после успешного завершения (поведение по умолчанию).

0 голосов
/ 12 июня 2019

Вы можете использовать плагин Schedule Build для планирования сборки длинного задания, когда короткое задание выполнено успешно.

Короткое задание запускается в каждой ветви, когда сборка завершается успешно для определенной ветви, она планирует сборку длинного задания (ночью) с параметром ветви in, поэтому длинное задание будет выполняться в этой конкретной ветви.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...