Наш экземпляр Jenkins в настоящее время сообщает BUILDS_ALL_TIME равным 999 для всех сборок всех заданий. Кто-нибудь еще испытал это и понял путь наименьшего сопротивления, чтобы заставить его обрабатывать эту переменную среды, как ожидалось?
Предыстория: вчера утром я обновил все плагины в нашем экземпляре Jenkins до последней стабильной версии . Требовалось обновить полдюжины или более плагинов, и я никогда не обращал на них пристального внимания, но плагин Credentials Binding не работал, потому что он покраснел мой монитор в связи с критическим обновлением безопасности и запустил весь процесс.
Вчера днем мой коллега заметил, что номер версии одной из его сборок изменился с 1.0.0.7 на 1.0.0.999, и я смог подтвердить то же самое с одной из моих. Теперь все задания, которые полагаются на отчет о переменной среды BUILDS_ALL_TIME
999
для этой переменной в каждой сборке.
Плагин Номер версии установлен и обновлен, и вот выдержка из сборки. xml из затронутой сборки:
<org.jvnet.hudson.tools.versionnumber.VersionNumberAction plugin="versionnumber@1.9">
<info>
<buildsToday>34</buildsToday>
<buildsThisWeek>40</buildsThisWeek>
<buildsThisMonth>40</buildsThisMonth>
<buildsThisYear>40</buildsThisYear>
<buildsAllTime>24</buildsAllTime> <!-- This is correct, is incremented properly between builds, and is updated appropriately when overridden in the job configuration GUI -->
</info>
<versionNumber>999.0.0</versionNumber> <!-- This is incorrect and NOT incremented properly between builds -->
</org.jvnet.hudson.tools.versionnumber.VersionNumberAction>
Время такого поведения, похоже, связано с обновлением плагинов (эта связь ни в коем случае не определена, но это лучшее, что у меня есть с этой точки зрения). Следовательно, я попытался понизить версию каждого плагина с этой опцией, доступной в управлении GUI, один за другим, чтобы посмотреть, смогу ли я найти одного виновника. Это было бесполезно. У меня нет возможности понизить версию плагина Version Number, но последний выпуск этой штуки был двухлетним go.