Блог

Главная - Вопросы по программированию - Конфигурация Hudson / Jenkins PMD

Конфигурация Hudson / Jenkins PMD

#ant #hudson #jenkins #pmd

#ant #хадсон #Дженкинс #pmd

Вопрос:

Я новичок в Jenkins и только начал его настраивать. Это то, что я делал до сих пор:

  1. Установил и настроил Jenkins для отображения домашней страницы. Добавлен плагин PMD.
  2. Установите HUDSON_HOME для определенного каталога> C:WorkJenkins
  3. Настроил тестовую сборку для запуска простого ничего не делающего ant-скрипта. Он выполняется успешно
  4. Написан независимый pmdbuild.xml для выполнения проверок набора файлов в C:myview (Я использую clearcase). Этот XML также копирует выходные данные pmd_results.xml в каталог рабочей области в $HUDSON_HOME/[job-name]/workspace
  5. Теперь я добавил pmdbuild.xml это как шаг в моей основной сборке. Итак, моя сборка состоит из 2 шагов: a. Запустите простой скрипт, ничего не делая. b. Запустите p mdbuild.xml , который сгенерирует pmd_results.xml и поместит его в $HUDSON_HOME/[job-name]/workspace (ЖЕСТКО ЗАПРОГРАММИРОВАННЫЙ, поскольку плагин Jenkins PMD ожидает там файл)
  6. Дженкинс pmd_results.xml автоматически подбирает плагин и отображает предупреждения и все остальное.

Теперь проблема:

  • Если я нажимаю на имя файла в результатах PMD, оно выдает filenotfound исключение, поскольку оно ищет исходный файл $HUDSON_HOME/[job-name]/workspace .
  • Мои файлы кода Java размещены в C:myview (представление моментального снимка clearcase)

Мой вопрос в том, нужно ли мне, чтобы все мои файлы кода присутствовали внутри $HUDSON_HOME/[job-name]/workspace ?? Значение не могу ли я сказать Дженкинсу искать входные файлы PMD в C:myview или любой другой каталог вместо $HUDSON_HOME/[job-name]/workspace ??

Извините за чрезвычайно длинное описание.

Ответ №1:

Дженкинс ожидает, что весь код находится в рабочей области. Обычно Jenkins используется для извлечения копии кода в рабочую область, а затем выполняет все этапы сборки для исходных текстов в рабочей области.

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

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

Если есть веские причины, по которым ваш код должен оставаться там, где он есть (C:myview в вашем случае) вы все равно можете установить рабочее пространство вашей сборки в этот каталог (найдите это на странице конфигурации задания, вам нужно нажать на кнопку «Расширенный», чтобы увидеть эту опцию).

Комментарии:

1. большое спасибо.. Я нашел эту опцию в конфигурации master Jenkins и устранил проблему. Не согласен с тем, что Дженкинс полностью проверяет мой код. Это должно быть скорее на индивидуальной основе, чем что-либо еще, а не принуждение.

2. Конечно, не каждая работа должна проверять исходные коды. Имеет большой смысл иметь одно задание, которое проверяет исходные тексты и создает их, другое, которое выполняет тесты на исходниках сборки, другое, которое выполняет некоторый анализ кода. Тем не менее, по-прежнему рекомендуется, чтобы Дженкинс проверял исходные тексты, а не делал это за пределами Jenkins. Если вы проверите исходные тексты с помощью Jenkins, вы получите много преимуществ (например, сохранение истории того, какие исходные изменения использовались в какой сборке и т.д.).

3. У меня была причина не проверять, поскольку мой исходный код содержит более 40 тысяч файлов, а clearcase не является git 🙂

Метки: