Удаление локального репозитория Maven на машине сборки

Question

На сервере сборки CI локальный репозиторий Maven периодически заполняет файловую систему (через несколько дней). Какую стратегию используют другие, чтобы урезать локальное хранилище в таком случае? -Макс

Answer 1

Плагин зависимостей Maven имеет цель purge-local-repository , которая позволяет вам удалить зависимости для данного проекта из локального репозитория, если это выполняется, скажем, раз в день для каждого проекта, снимки не будет накапливаться.

---

В качестве альтернативы вы можете использовать более выжженный подход. Поскольку проблема обычно заключается в артефактах моментальных снимков с метками времени, вы можете использовать maven-antrun-plugin , чтобы удалить все файлы, которые соответствуют шаблону сбора ресурсов.

Например (обратите внимание, что это может потребовать некоторой настройки, как я сделал это из памяти):

<plugin>
  <artifactId>maven-antrun-plugin</artifactId>
  <executions>
    <execution>
      <phase>package</phase>
      <configuration>
        <tasks>
          <delete>
            <fileset dir="${settings.localRepository}">
              <include name="**/*.jar"/>
              <exclude name="**/*.pom"/>
              <exclude name="**/*.war"/>
              <exclude name="**/*.ear"/>
              <exclude name="**/*.md5"/>
              <exclude name="**/*.sha"/>
              <!--any other extensions?...-->
              <!--match the timestamp pattern-->
              <containsregexp expression="[0-9]{8}.[0-9]{6}-[0-9]+"/>
            </fileset>
          </delete>
        </tasks>
      </configuration>
      <goals>
        <goal>run</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Answer 2

Если вы используете Hudson, вы можете настроить запланированное задание, чтобы просто удалять весь репозиторий один раз в день или что-то подобное У меня есть работа под названием hudson-maven-repo-clean, которая имеет такую ​​конфигурацию:

• Сборка / выполнение оболочки: rm -rf ~hudson/.m2/repository
• Построить триггеры / Построить периодически: 0 0 * * *

Answer 3

В дополнение к локальному репозиторию purge (который читается мне как ядерный вариант, поскольку он предлагает только конфигурацию excludes, а не явную includes), взгляните на Project Remove Артефакт Мохо . Я пытаюсь реализовать это сейчас, поскольку мой точный вариант использования - очистить большие снимки WAR и EAR, которые строятся на моих компьютерах CI (и иногда рабочей станции).

Answer 4

Мы специально используем для этой цели плагин build-helper . В нашей компании родительский pom - это цель удаления-проекта-артефакта, встроенная в профиль для наших сборок Hudson. Таким образом, все старые версии этого артефакта удаляются перед установкой текущей версии сборки.

...
<profile>
  <id>hudson</id>
  <activation>
    <property>
      <name>BUILD_TAG</name>
    </property>
  </activation>
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>build-helper-maven-plugin</artifactId>
        <version>1.7</version>
        <executions>
          <execution>
            <id>remove-old-artifacts</id>
            <phase>package</phase>
            <goals>
              <goal>remove-project-artifact</goal>
            </goals>
            <configuration>
              <removeAll>true</removeAll>
            </configuration>
          </execution>
        </executions>
      </plugin>
  ...

Использование removeAll со значением true уничтожит все другие снимки, кроме того, над которым вы работаете. Это может быть опасно, так как это может означать, что снимки для ветки также будут уничтожены.

Например, если у вас есть снимок 1.0.0.18-SNAPSHOT, представляющий HEAD, и снимок 1.0.1.17-SNAPSHOT, представляющий ветвь, запуск этого плагина со сборкой 1.0.0.18-SNAPSHOT приведет к удалению папки 1.0.1.17-SNAPSHOt.

Чтобы обойти этот сценарий, для removeAll должно быть установлено значение false.

Answer 5

Мы использовали немного другую (и коварную) технику. У всех артефактов, которые создают «большие вещи» (EAR, WAR, TAR), местоположение развертывания переопределяется следующим образом:

<properties>
   <discard-me-in-bit-bucket>file://${basedir}/target/_DELETEME</discard-me-in-bit-bucket> 
</properties>

<distributionManagement>
  <repository>
    <id>upload-InternalSite</id>
    <name>SoftwareLibrary External</name>
    <url>${discard-me-in-bit-bucket}</url>
    <layout>legacy</layout>
    <uniqueVersion>false</uniqueVersion>
  </repository>
  <snapshotRepository>
    <id>upload-InternalSite</id>
    <name>Repository Name</name>
    <url>${discard-me-in-bit-bucket}</url>
    <layout>legacy</layout>
    <uniqueVersion>false</uniqueVersion>
  </snapshotRepository>
</distributionManagement>

Эта стратегия заставляет цель развертывания помещать вещи в целевой каталог, который, конечно, будет уничтожен следующей операцией CLEAN. Чтобы стать еще более агрессивным, у нас есть шаг после сборки, который делает это:

find -type d -name '*_DELETEME' -exec rm -rf '{}' ';' -prune || echo $?

Мы также используем еще одну стратегию. В Hudson / Jenkins мы предоставляем файл настроек для размещения репозитория .m2 в рабочей области для работы. Это позволяет нам удалить весь репозиторий до или после работы. Это также делает артефакты видимыми в рабочей области, что помогает при отладке некоторых проблем.

Answer 6

Насколько велика файловая система? У нас есть 10 ГБ, выделенных для сборок и снимков, сделанных старше 30 дней каждую ночь. Это похоже на работу

Вы делаете сборки каждые X часов или когда код меняется? Переключение на изменения кода уменьшит количество артефактов без уменьшения покрытия.

Вы устанавливаете все снимки локально? Вам не нужно делать это во всех случаях. В большинстве случаев только те снимки, которые являются активно разработанными зависимостями, должны быть установлены локально.

Вы устанавливаете файлы EAR / WAR локально? Тебе, вероятно, они тоже не нужны.

Сколько рабочих мест у вас есть? Мы используем Hudson и сохраняем только последние 5 сборок.