Ошибка теста gradle при использовании slackNotifier в определении Jenkins Job DSL

Обновление: в нижней части записи вики-страницы "Автоматически созданный DSL" ... The generated DSL is only supported when running in Jenkins,....

Поскольку slackNotifier генерирует DSL, похоже, что нет способа проверить это в нашей конкретной инфраструктуре. Мы собираемся написать функцию, которая генерирует конфигурацию с помощью блока configure.

У меня есть определение начального задания, которое не работает gradle test, хотя кажется, что оно работает нормально, когда мы его используем в Дженкинсе.

Определение вакансии Выдержка

//package master
// GitURL
def gitUrl = 'https://github.com/team/myapp'
def slackRoom = null

job('seed-dsl') {
    description('This seed is updated from the seed-dsl-updater job')
    properties {
        //Set github project URL
        githubProjectUrl(gitUrl)
    }
    ...
    // publishers is another name for post build steps
    publishers {
        mailer('', false, true)
        slackNotifier {
            room(slackRoom)
            notifyAborted(true)
            notifyFailure(true)
            notifyNotBuilt(true)
            notifyUnstable(true)
            notifyBackToNormal(true)
            notifySuccess(false)
            notifyRepeatedFailure(false)
            startNotification(false)
            includeTestSummary(false)
            includeCustomMessage(false)
            customMessage(null)
            buildServerUrl(null)
            sendAs(null)
            commitInfoChoice('NONE')
            teamDomain(null)
            authToken(null)
        }
    }
}

Команда gradle test отлично работает, когда я закомментирую ее с помощью объявления slackNotifier, но не работает со следующей ошибкой, когда она включена:

Тестовый вывод отрывок

Caused by:
        javaposse.jobdsl.dsl.DslScriptException: (script, line 79) No signature of method: javaposse.jobdsl.dsl.helpers.publisher.PublisherContext.slackNotifier() is applicable for argument types: (script$_run_closure1$_closure9$_closure14) values: [script$_run_closure1$_closure9$_closure14@d2392a1]
        Possible solutions: stashNotifier(), stashNotifier(groovy.lang.Closure)
            at javaposse.jobdsl.dsl.DslScriptLoader.runScriptEngine(DslScriptLoader.groovy:135)
            at javaposse.jobdsl.dsl.DslScriptLoader.runScriptsWithClassLoader_closure1(DslScriptLoader.groovy:78)

Согласно документу миграции, slackNotifer поддерживается с 1.47. В моем gradle.build я использую 1.48. Я вижу те же ошибки с версией плагина 1.50

Выдержка gradle.build

ext {
 jobDslVersion = '1.48'
 ...
}
...
// Job DSL plugin including plugin dependencies
testCompile "org.jenkins-ci.plugins:job-dsl:${jobDslVersion}"
testCompile "org.jenkins-ci.plugins:job-dsl:${jobDslVersion}@jar"
...

Как указано в [документации тестирования] * (https://github.com/jenkinsci/job-dsl-plugin/wiki/Testing-DSL-Scripts).

testPlugins 'org.jenkins-ci.plugins:slack:2.0.1'

Что мне нужно сделать, чтобы успешно протестировать свои определения вакансий. Это ошибка или я что-то еще пропустил?


jenkins jenkins-job-dsl
person Community    schedule 02.09.2016    source источник

Ответы (2)


arrow_upward
1
arrow_downward

удален неверный ответ

РЕДАКТИРОВАТЬ

Вижу, я упустил суть.

Новый подход заключается в повторном использовании @DataBoundConstructor, предоставляемого плагинами, поэтому ничего не нужно писать для поддержки нового плагина, если у него есть DataBoundConstructor.

Ваш SlackNotifier есть это - обратите внимание, что DSL преобразует за вас первую строчную букву

@DataBoundConstructor
public SlackNotifier(
    final String teamDomain, 
    final String authToken, 
    final String room, 
    final String buildServerUrl,
    final String sendAs, 
    final boolean startNotification, 
    final boolean notifyAborted, 
    final boolean notifyFailure,
    final boolean notifyNotBuilt, 
    final boolean notifySuccess, 
    final boolean notifyUnstable, 
    final boolean notifyBackToNormal,
    final boolean notifyRepeatedFailure, 
    final boolean includeTestSummary, 
    CommitInfoChoice commitInfoChoice,
    boolean includeCustomMessage, 
    String customMessage) {
    ...
}

К сожалению, в списке параметров есть встроенный тип CommitInfoChoice, и у него нет DataBoundConstructor и его enum тоже.

public enum CommitInfoChoice {
    NONE("nothing about commits",                             false, false),
    AUTHORS("commit list with authors only",                  true,  false),
    AUTHORS_AND_TITLES("commit list with authors and titles", true,  true);
    ...
}

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

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

Вы можете попробовать job dsl google group - ссылка на сообщение об общем подходе

person KeepCalmAndCarryOn    schedule 02.09.2016
comment
Как я уже сказал в своем вопросе, документ миграции отмечает, что, поскольку версия 1.47 slackNotifications устарела и заменена slackNotifer, нет, я не хочу использовать устаревший DSL. - person ; 06.09.2016
comment
Я изменил свой ответ, надеюсь, лучше, но, вероятно, не очень хорошие новости - person KeepCalmAndCarryOn; 07.09.2016
comment
Я пришел к такому же выводу, но вы предоставили некоторые важные детали. Спасибо. - person ; 07.09.2016
comment
перечисления не обязательно должны иметь @DataBoundConstructor, вы можете использовать значения перечисления непосредственно как строки, например. 'NONE' или 'AUTHORS_AND_TITLES' для перечисления CommitInfoChoice. - person daspilker; 13.09.2016

arrow_upward
0
arrow_downward

Мы тоже столкнулись с этим. Решением для нас было добавить версию плагина Slack, которую мы использовали на jenkins, в наш список плагинов в Gradle.

Чтобы быть более конкретным, в нашем build.gradle файле в разделе зависимостей мы добавили следующий код, чтобы включить наши плагины и, следовательно, позволить автоматически сгенерированному DSL работать.

Вы можете увидеть это здесь, а также пример другого плагина рядом с testPlugins:

Как следующее:

dependencies {
  ...
  // plugins to install in test instance
  testPlugins 'org.jenkins-ci.plugins:ghprb:1.31.4'
  testPlugins 'com.coravy.hudson.plugins.github:github:1.19.0'
}
person cdoughty    schedule 23.06.2017