Айви, Ant, Дженкинс - Это хорошая идея для <ivy: cleancache> на сборках Дженкинса?

Мы собираемся использовать Ivy с Ant, и у нас будет Jenkins делать наши сборки. Первоначально я думал, что если Jenkins сделает <ivy:cleancache/> перед запуском сборки, это будет хорошей идеей. (Это будет часть обязательной "чистой" цели).

Однако теперь я вижу, что <ivy:cleancache> не просто очищает материал от <ivy:cachepath>, но действительно удаляет весь каталог $HOME/.ivy/cache.

Мое беспокойство заключается в том, что если Дженкинс делает <ivy:cleancache> во всех сборках до их запуска, это будет мешать другим сборкам, которые мог выполнять Jenkins.

Делает <ivy:cleancache> хорошую идею, особенно если один пользователь может делать несколько сборок одновременно?

На самом деле, что происходит, когда вы выполняете <ivy:cachepath pathid="compile.path"/> в нескольких проектах? Это также влияет на что-то вроде Дженкинса? Будет ли Дженкинс запутаться, если несколько сборок строят compile.cachepath в то же время?

Ответ 1

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

Сказав, что, как указано в следующем связанном Maven вопросе, все кеши могут стать грязными и должны периодически удаляться:

Когда безопасно удалять локальный репозиторий Maven?

Несколько рекомендаций:

Использовать целевые задания Jenkins для очистки кэша плюща

Моя первая рекомендация - создать периодическое задание Jenkins, которое вызывает следующую чистую цель в вашей сборке:

<target name="clean-all" depends="clean">
   <ivy:cleancache/>
</target>

Это гарантирует, что Дженкинс решает, когда очищается кеш, и вы можете запланировать его за пределами обычного времени сборки (например, 2 утра 1-го числа каждого месяца).

Изолировать каждый проект с помощью нескольких кешей

Моя вторая рекомендация увеличивает изоляцию между вашими проектами. Настройте каждый проект, чтобы он имел собственный кеш, используя директиву caches. в вашем файле настроек плюща.

Ответ 2

Вот что я решил сделать:

Я изменил свой файл ivysettings.xml, чтобы иметь следующее:

<ivysettings>
    <properties environment="env." override="false"/>
    <caches
        defaultCacheDir="${ivy.default.ivy.user.dir}/cache-${env.EXECUTOR_NUMBER}"
        resolutionCacheDir="${ivy.dir}/../target/ivy.cache"/>
    <settings defaultResolver="default"/>
    <include file="${ivy.dir}/ivysettings-public.xml"/>
    <include url="${ivy.default.settings.dir}/ivysettings-shared.xml"/>
    <include url="${ivy.default.settings.dir}/ivysettings-local.xml"/>
    <include url="${ivy.default.settings.dir}/ivysettings-main-chain.xml"/>
    <include url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/>
</ivysettings>

Это делает две вещи:

  • Он определяет локальный кеш Ivy как $HOME/.ivy/cache-$EXECUTOR_NUMBER, где $EXECUTOR_NUMBER является исполнителем Jenkins. Это означает, что каждый исполнитель получает свой кеш Ivy. Таким образом, если Дженкинс выполняет более одной работы за раз, каждое задание будет подхвачено другим исполнителем, поэтому он будет иметь свой собственный кеш. Если задание хочет очистить кеш, оно может идти прямо вперед.
  • Я определил кеш разрешения ${basedir}/target/ivy.cache. Это дает каждой работе собственный кэш-память резольвера, которая довольно мала. Но, таким образом, разрешение плюща не мешает другим работам, если Дженкинс строит несколько версий одного и того же проекта Ivy.

Единственный недостаток заключается в том, что каталог кэша по умолчанию пользователя называется $HOME/.ivy/cache-$env.EXECUTOR_NUMBER, который не является хорошим сайтом. Я бы хотел сделать его более разумным $HOME/.ivy/cache-0, но я этого не понял. Однако на данный момент это ничего не влияет.

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

Между тем, Дженкинс может очищать кеш Ivy так часто, как он настроен. Это может быть сделано для каждой работы, или один раз в день, или в месяц. Однако, поскольку кеш выполняется для каждого исполнителя, у меня не будет проблемы с очисткой кэша, в то время как другое задание (которое будет выполняться на другом исполнителе) зависит от этого кеша.

Это должно решить все конкретные проблемы. Единственное, что я хотел бы сделать, это выяснить, как установить переменную EXECUTOR_NUMBER, если она еще не установлена. Я пробовал такие вещи:

<ivysettings>
    <property name="env.EXECUTOR_NUMBER" value="0" override="false"/>
    <properties environment="env." override="false"/>
    <caches
        defaultCacheDir="${ivy.default.ivy.user.dir}/cache-${env.EXECUTOR_NUMBER}"
        resolutionCacheDir="${ivy.dir}/../target/ivy.cache"/>
    <settings defaultResolver="default"/>
    <include file="${ivy.dir}/ivysettings-public.xml"/>
    <include url="${ivy.default.settings.dir}/ivysettings-shared.xml"/>
    <include url="${ivy.default.settings.dir}/ivysettings-local.xml"/>
    <include url="${ivy.default.settings.dir}/ivysettings-main-chain.xml"/>
    <include url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/>
</ivysettings>

Но безрезультатно. Я по-прежнему изменял параметры override как в файлах <property>, так и <properties> по-разному, но он не совсем делает то, что я хочу.

Ответ 3

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

Вы можете добавить это в свойства Jenkins Ant Build Steps

another.less.obtrusive.name=${EXECUTOR_NUMBER}

и добавьте в ivysettings.xml.

Таким образом, для всех будет "0", за исключением Jenkins, потому что он будет вводить это свойство в ANT.

Что-то по основному вопросу: На Дженкинсе я всегда начинаю новый. CI-сборки должны быть надежными, тщательными. Fast - приветствуемый побочный продукт, но не мотивация.