Не удалось интегрировать Bugzilla Testopia с Jenkins с помощью Testopia Plugin - не может выполнить какой-либо итеративный шаг сборки

Question

Я пытаюсь интегрировать Bugzilla Testopia с Jenkins с помощью плагина Testopia для Jenkins.

Общая конфигурация, вероятно, прекрасна, поскольку связь между Testopia и Jenkins хорошо установлена ​​(Jenkins log говорит: «Подключение к Testopia для извлечения автоматизированных тестовых случаев», и при этом не возникает ошибок). Однако я не могу получить информацию о Test Runs/Test Cases и т. Д. От Testopia.

Кроме того, я не могу выполнить ни одну из «Итеративных тестовых шагов сборки». Если я хочу «Выполнять оболочку» в «Итеративных тестовых этапах сборки» с помощью плагина Testopia, операция не выполняется (даже если я пытаюсь: echo 12345 и т. Д.). Если я использую «Single Test Build Steps», тогда выполняется команда shell.

Моя цель - получить имя тестового класса из Testopia (оно хранится в поле Testopia Test Case - Automation/Scripts), а затем запустить maven build из Jenkins с этим именем класса, установленным в качестве параметра. Впоследствии, в зависимости от успеха или статуса неудачи Jenkins, я хотел бы обновить статус тестового случая в Testopia.

Как получить любую информацию от Testopia в Jenkins? Почему ни одна из «Итеративных тестовых шагов сборки» не выполняется? Любые подсказки? - Пример сайта Plugop для Testopia был не слишком полезен для меня.

Оба Bugzilla и Jenkins расположены на том же Ubuntu 14.04. У меня есть последние стабильные версии Jenkins, Bugzilla и Testopia.

Спасибо заранее, М.

EDIT:

Ну это отладка не работает для меня. Я добавил новый записывающий рекордер с выбранным уровнем «ВСЕ», и я не вижу никакого дополнительного журнала ни на выходе консоли, ни на новом выпуске журнала.

Может быть, что-то не так с моей установкой Testopia? Некоторые подробности о моей конфигурации:

У меня установлена ​​Testopia на той же машине (как Дженкинс), и обычно я получаю ее через: http: // 'ip_address'/bugzilla - в конфигурации плагина Testopia мой URL-адрес Установка Testopia: http: //'ip_address'/bugzilla/xmlrpc.cgi - У меня есть только одна учетная запись bugzilla - эти учетные данные администратора, которые я использую в Jenkins - иногда в Jenkins. Я вижу предупреждение о неправильной конфигурации обратного прокси-сервера - возможно, это связано с проблемой.

После выполнения задания все поля Testopia равны 0 - Идентификатор запуска, Идентификатор сборки и т. д. - что, очевидно, указывает на то, что информация не была успешно извлечена из Testopia.

Любые идеи, как проверить, почему я не могу получить информацию из Testopia?

EDIT 2:

В то же время я думаю, что я нашел ключ в jenkins.log файл в каталоге установки Дженкинс:

Исключения, как это происходит: INFO: TESTOPIA_TEST_SUITE_3 # 13 основной сборки действие завершено: SUCCESS org.apache.xmlrpc.XmlRpcException: запрошенный метод «TestRun.get» не найден. at org.apache.xmlrpc.client.XmlRpcStreamTransport.readResponse (XmlRpcStreamTransport.java:197) ... org.apache.xmlrpc.XmlRpcException: запрошенный метод «TestRun.get_test_cases» не найден. at org.apache.xmlrpc.client.XmlRpcStreamTransport.readResponse (XmlRpcStreamTransport.java:197)

Должен ли я вставить полный стек?

Answer 1

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

Для отладки дальше, вы можете попробовать adding a new log recorder для регистратора jenkins.plugins.testopia (с уровня журнала «все»), запустить сборку, а затем обновить веб-страницу для вновь созданного журнала рекордера, чтобы увидеть выход.

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

Answer 2

У меня возникла аналогичная проблема, когда я использую python xmlrpc для обмена сообщениями с моим сервером bugzilla-testopia.

Код ошибки и найдите XMLRPC.pm под моим местоположением установки bugzilla: «./WebService/Server/XMLRPC.pm».

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

sub handle_login { 

... 

if (none { $_ eq $method } $class->PUBLIC_METHODS) { 
ThrowCodeError('unknown_method', { method => $full_method }); 
} 
... 
} 

Я не знаю, почему, но TestCase.get не удалось найти в PUBLIC_METHODS, поэтому я просто отметил их как комментарий, а затем он работает. Вы можете сделать это быстро, чтобы убедиться, что ваша настройка клиента верна. Затем вы должны решить проблему «PUBLIC_METHODS».