Используя Jenkins, Perforce и Ant, как я могу запускать PMD только для файлов, которые изменились с момента последней зеленой сборки?

Question

Учитывая, что:

• Кажется, что нет простого способа получить список "измененных" файлов в Jenkins (см. здесь и здесь )
• Кажется, что нет быстрого способа изменить список файлов, так как метка xxxx

Как я могу оптимизировать нашу сборку, чтобы при запуске PMD она работала толькодля файлов, которые были изменены с момента последней зеленой сборки.

Немного резервного копирования ... нашему PMD требуется 3–4 минуты, чтобы выполнить ~ 1,5 миллиона строк кода, и, если он обнаруживает проблему, отчет неизменно запускаетсяНедостаточно памяти до его завершения.Я бы хотел урезать пару минут нашего времени сборки и получить хороший отчет о сбоях.Мой первоначальный подход заключался в том, чтобы я:

• получил список изменений от Jenkins
• , запустил PMD для объединения этого списка и содержимого pmd_failures.txt
• если PMD дает сбой, включите список сбойных файлов в pmd_failures.txt

Сложнее, чем хотелось бы, но стоит иметь более быструю, но надежную сборку.

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

Без кубиков.Идея получения списка файлов изменилась, поскольку метка xxxx от Perforce, кажется, никогда не была упорядочена из:

    $ p4 files //path/to/branch/...@label > label.out
    $ p4 files //path/to/branch/...@now > now.out
    $ diff label.out now.out

Раздражает, но, что еще важнее, даже медленнее для многих тысяч наших файлов, чем просто запуск PMD.

Итак, теперь я пытаюсь запустить PMD параллельно с другими компонентами сборки, которые по-прежнему тратят впустую время и ресурсы и делают нашу сборку более сложной.Мне кажется глупым, что я не могу легко получить список измененных файлов от Дженкинса или от Perforce.Кто-нибудь еще нашел разумное решение этих проблем?

Answer 1

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

Это немного сложнее, чем хотелось бы, но я думаю, что стоит сэкономить 3-4 минуты (и потенциальные проблемы с памятью).

1. В конце хорошей сборки сохраните хороший список изменений в качестве счетчика Perforce. (задание после сборки). Выглядит так:

   $ p4 counter last_green_trunk_cl %P4_CHANGELIST%
   

2. При запуске PMD считайте счетчик в свойстве last.green.cl и получите список файлов:

   $ p4 files //path/to/my/branch/...@${last.green.cl},now
   //path/to/my/branch/myfile.txt#123 - edit change 123456 (text)
   //path/to/my/branch/myotherfile.txt#123 - add change 123457 (text)
   etc...
   (have to parse the output)
   

3. Запуск PMD для этих файлов.

Таким образом, нам не нужен pmd_failures.txt, и мы запускаем PMD только для файлов, которые изменились с момента последней зеленой сборки.

[РЕДАКТИРОВАТЬ: изменил его, чтобы использовать счетчик p4, который намного быстрее, чем проверка в файле. Кроме того, это было очень успешно, поэтому я отмечу это как ответ]

Answer 2

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

Answer 3

Я не уверен на 100%, поскольку никогда не использовал Perforce с Jenkins, но я считаю, что Perforce передает номер списка изменений через переменную окружения $P4_CHANGELIST. При этом вы можете запустить p4 filelog -c $P4_CHANGELIST, который должен предоставить вам файлы из этого конкретного списка изменений. Оттуда не должно быть сложно что-то написать, чтобы просто получить измененные файлы (плюс старые сбои в PMD).

Я давно не использовал Perforce, но я считаю, что параметр -Ztag облегчает анализ выходных данных P4 для различных языков сценариев.