maven 2 - teoria - Eliminando el repositorio local de Maven en la máquina de compilación
pom maven (6)
En un servidor de compilación de CI, el repositorio local de Maven llena el sistema de archivos repetitivamente (después de unos días). ¿Qué estrategia están haciendo otros para recortar el repositorio local en tal caso? -Max
¿Qué tan grande es el sistema de archivos? Tenemos 10gb asignados a compilaciones y zap instantáneas de más de 30 días cada noche. Eso parece funcionar
¿Estás haciendo compilaciones cada X horas o cuando cambia el código? Cambiar a cambios de código reducirá la cantidad de artefactos sin reducir la cobertura.
¿Está instalando todas las instantáneas localmente? No es necesario hacer esto en todos los casos. En la mayoría de los casos, solo las instantáneas que son dependencias desarrolladas activamente deben instalarse localmente.
¿Está instalando archivos EAR / WAR localmente? Probablemente tampoco los necesites.
¿Cuántos espacios de trabajo mantienes? Usamos hudson y mantenemos solo las últimas 5 versiones.
Además de purge-local-repository (que me parece una opción nuclear, ya que solo ofrece una configuración de exclusión y no una explícita), eche un vistazo al mojo Eliminar artefacto del proyecto . Estoy tratando de implementarlo ahora, ya que mi caso de uso exacto es borrar las grandes instantáneas WAR y EAR que se están construyendo en mis máquinas CI (y, a veces, estaciones de trabajo).
El complemento de dependencia de Maven tiene un objetivo de purge-local-repository que le permite eliminar las dependencias para un proyecto dado del repositorio local, si se ejecuta una vez al día en cada proyecto, las instantáneas no se acumularán.
Alternativamente, hay un enfoque de la tierra quemada que podrías tomar. Como el problema suele ser los artefactos de instantáneas con marca de tiempo, puede usar el maven-antrun-plugin para eliminar todos los archivos que coincidan con el patrón de colección de recursos.
Por ejemplo (tenga en cuenta que esto podría necesitar algunos ajustes, ya que lo he hecho de la memoria):
<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>
Hemos empleado una técnica ligeramente diferente (y desviada). Todos los artefactos que construyen "cosas grandes" (EAR, WAR, TAR) tienen su ubicación de despliegue anulada de esta forma:
<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>
Esta estrategia hace que el objetivo del despliegue sea poner las cosas en el directorio de destino, que, por supuesto, se destruye con la siguiente operación LIMPIAR. Para ser aún más agresivos, tenemos un paso posterior a la construcción que hace esto:
find -type d -name ''*_DELETEME'' -exec rm -rf ''{}'' '';'' -prune || echo $?
También empleamos una estrategia más. En Hudson / Jenkins proporcionamos un archivo de configuración para colocar el repositorio .m2 en el área de trabajo para el trabajo. Esto nos permite eliminar todo el repositorio antes o después del trabajo. También hace que los artefactos sean visibles en el área de trabajo, lo que ayuda a depurar algunos problemas.
Si está usando hudson, puede configurar un trabajo programado para eliminar todo el repositorio una vez al día o algo así. Tengo un trabajo llamado hudson-maven-repo-clean que tiene esta configuración:
- Construir / Ejecutar shell:
rm -rf ~hudson/.m2/repository - Construir disparadores / Construir periódicamente:
0 0 * * *
Usamos especialmente para este propósito el complemento de compilación auxiliar . En nuestra empresa, pom principal es el objetivo de eliminar artefacto de proyecto incrustado en el perfil para nuestras compilaciones de hudson. De esta manera, todas las versiones anteriores de este artefacto se eliminan antes de instalar la versión de compilación actual.
...
<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>
...
El uso de removeAll establecido en verdadero eliminará todas las demás instantáneas, excepto la que está trabajando. Esto puede ser peligroso, ya que puede significar que las instantáneas de una rama también serán eliminadas.
Por ejemplo, si tiene una instantánea 1.0.0.18-SNAPSHOT que representa HEAD y una instantánea 1.0.1.17-SNAPSHOT que representa una rama, ejecutar este complemento con la compilación 1.0.0.18-SNAPSHOT borrará la carpeta 1.0.1.17-SNAPSHOt.
Para sortear este escenario, removeAll se debe establecer en false.