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

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

  1. Установил и настроил Jenkins для отображения домашней страницы. Добавлен плагин PMD.
  2. Установите HUDSON_HOME в определенный каталог > C:\Work\Jenkins

  3. Настроил тестовую сборку для запуска простого ничего не делающего скрипта ant. Он работает успешно

  4. Написал независимый pmdbuild.xml для проверки набора файлов в C:\myview (я использую clearcase). Этот xml также копирует вывод pmd_results.xml в каталог рабочей области в $HUDSON_HOME/[job-name]/workspace.

  5. Теперь я добавил pmdbuild.xml в качестве шага в моей основной сборке. Итак, моя сборка состоит из 2 шагов: а. Запустите простой скрипт, ничего не делая. б. Запустите pmdbuild.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 (представление моментального снимка в прозрачном регистре)

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

Извините за очень длинное описание.


jenkins ant hudson pmd
person Pulak Agrawal    schedule 31.10.2011    source источник

Ответы (1)


arrow_upward
3
arrow_downward

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

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

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

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

person pushy    schedule 31.10.2011
comment
большое спасибо .. Я обнаружил эту опцию в конфигурации master Jenkins и исправил проблему. Не согласен с тем, что Дженкинс полностью проверяет мой код. Это должно быть больше от случая к случаю, чем что-либо еще, а не принуждение. - person Pulak Agrawal; 31.10.2011
comment
Конечно, не каждая работа должна проверять источники. Имеет смысл иметь одно задание, которое проверяет исходники и их сборку, другое — выполнение тестов на исходниках сборки, третье — выполнение некоторого анализа кода. Тем не менее, по-прежнему рекомендуется, чтобы Дженкинс проверял исходники, а не делал это за пределами Дженкинса. Если вы проверите исходники с помощью Jenkins, вы получите много преимуществ (например, сохранение истории того, какие исходные изменения использовались в какой сборке и т. д.). - person pushy; 01.11.2011
comment
У меня была причина не проверять, так как мой исходный код содержит более 40 000 файлов, а clearcase не является git :) - person Pulak Agrawal; 07.09.2012