在CI构建服务器上,本地Maven存储库会重复填充文件系统(几天后)。 在这种情况下,其他人采取了什么策略来修剪本地存储库? -max
答案 0 :(得分:27)
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>
答案 1 :(得分:18)
如果你正在使用hudson,你可以设置一个预定的作业,每天只删除整个存储库或类似的东西。我有一份名为hudson-maven-repo-clean
的工作,它具有以下配置:
rm -rf ~hudson/.m2/repository
0 0 * * *
答案 2 :(得分:4)
除了purge-local-repository(它像核选项一样向我读取,因为它只提供excludes
配置而不是显式includes
),请查看{ {3}}。我现在想要实现它,因为我的确切用例是清除在我的CI(有时是工作站)机器上构建的大型WAR和EAR快照。
答案 3 :(得分:3)
我们特别为此目的使用build-helper plugin。在我们公司的父pom中,嵌入在我们的hudson构建的配置文件中的remove-project-artifact目标。这样,在安装当前构建版本之前,将删除此工件的所有旧版本。
...
<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将清除除您正在处理的快照之外的所有其他快照。这可能很危险,因为它可能意味着分支的快照也将被删除。
例如,如果您有一个代表HEAD的快照1.0.0.18-SNAPSHOT和代表分支的快照1.0.1.17-SNAPSHOT,则运行此插件的1.0.0.18-SNAPSHOT版本将擦除1.0.1.17-SNAPSHOt文件夹。
要解决此问题,应将removeAll设置为false。
答案 4 :(得分:1)
我们采用了一种略有不同(和狡猾)的技术。构建“大型事物”(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存储库放置在作业的工作空间中。这允许我们在作业之前或之后删除整个存储库。它还可以在工作区中显示工件,这有助于调试一些问题。
答案 5 :(得分:0)
文件系统有多大?我们已经为每晚30天以上的构建和zap快照分配了10gb。这似乎有效
您是否每隔X小时或代码更改时进行构建?切换到代码更改将减少工件数量而不会降低覆盖率。
您是否在本地安装所有快照?在所有情况下都不需要这样做。在大多数情况下,只需要在本地安装那些主动开发的依赖项快照。
您是在本地安装EAR / WAR文件吗?你可能也不需要它们。
你要保留多少个工作空间?我们使用hudson并仅保留最后5个版本。