Cómo prevenir la sobreescritura de los artefactos lanzados (versiones no instantáneas) en repositorio de Maven en Hudson

Question

Descripción del problema

Consideremos el caso experta se está utilizando en Hudson.

Ahora alguien tomó el pago de un proyecto, modificó algunos archivos pero accidentalmente usó la misma ID de artefacto y el número de versión (no instantánea).

Él/Ella luego construye este proyecto en hudson y lo hizo instalar. El artefacto modificado ahora está en hudson .m2. Cualquier otro proyecto que dependa de él será construido con artefactos modificados. Nadie lo descubre si la compilación no falla. A pesar de que el artefacto correcto reside en el repositorio central, nunca se usa porque se recogió uno modificado de .m2 cuando hudson comienza a construir.

Así que estoy buscando una forma de prevenir este error humano accidental.

1. De todos modos, para revocar los permisos de maven, instálelos en versiones no instantáneas (artefactos liberados) en hudson?
2. ¿Alguna forma de comparar las sumas de comprobación de .m2 en hudson y en el repositorio central remoto para que las fallas de suma de comprobación puedan generar advertencias o fallas en la compilación?

Ya he comprobado que no hay forma de forzar la actualización de versiones que no sean instantáneas desde el repositorio central ya que están destinadas a ser inmutables.

Depurar el repositorio central o usar un repositorio separado para cada trabajo en hudson dará como resultado un incremento en el tiempo de compilación & de espacio de disco respectivamente.

Cualquier ayuda sería apreciada.

Answer 1

No había manera directa para resolver esto, pero nos resolvió este inderctly escribiendo un trabajo programado que se ejecuta cada cinco minutos y marcas de todo el frascos que NO SON SNAPSHOT como leídos solo en el repositorio local de Hundson. De esta manera, cuando algún proyecto en Hudson trata de sobreescribirlo, mi mvn install o mvn deploy falla en overwiriting de los artefactos, ya que son de solo lectura.

Cualquier nuevo artefacto que se libere puede escribirse fácilmente. Una vez escrito dentro de los próximos cinco minutos, el guión los marca como de solo lectura.

Aquí es el código de secuencia de comandos UNIX permission-handler.sh

#!/bin/bash 
cd ~/.m2 
date 2>&1>> permission-handler.out 
find . -name '*jar' -type f | grep -v 'SNAPSHOT' | xargs chmod -vc 444 2>&1>> permission-handler.out 
chmod 777 permission-handler.out 

registro también se maneja para ver lo que todos los artefactos han sido marcados como se presenta solamente.

Answer 2

No creo que encuentre una manera de evitar que una instalación sobrescriba un artefacto. Sin embargo, un servidor de repositorio debe tener una configuración para evitar la implementación de un artefacto de lanzamiento actualizado. Consulte, por ejemplo, "How do I disable artifact redeployment" para Nexus.

Answer 3

Aquí es cómo manejamos versiones en nuestro proyecto:

Trabajamos en una versión SNAPSHOT. En Jenkins, tenemos un trabajo Fast Build que crea y prueba esta aplicación, pero falla si la versión es no a SNAPSHOT. Esto se hace mediante un custom enforcer (esto es lo opuesto al require release version enforcer).

Cuando queremos hacer un lanzamiento, utilizamos un trabajo de Jenkins para eso. Con el parameterized build y el Maven release plugin, la persona que está a cargo de realizar el lanzamiento solo indicará la versión del lanzamiento (la versión estable), la siguiente versión SNAPSHOT, así como el nombre de la etiqueta SCM. Por lo tanto, solo Jenkins definirá una versión estable y los desarrolladores siempre trabajarán en un código SNAPSHOT.

Pero, por supuesto, esto no impide que los desarrolladores hagan lo que él quiere en su máquina local. Pero siempre consideramos un lugar confiable: el servidor Jenkins.Funciona en mi máquina nunca es una buena respuesta a un problema; o)

Answer 4

Esto se soluciona configurando su repositorio Maven (por ejemplo, Nexus, Artifactory) para que no se sobrescriba el repositorio de versiones. En Nexus tenemos un informe para SNAPSHOT y otro para lanzamientos. El repositorio SNAPSHOT permite sobrescribir. Pero el repositorio de publicación no permite sobrescribir. Esta es solo una característica de casilla de verificación simple en Nexus para ese repositorio. Una vez que se coloca una versión de lanzamiento en el repositorio, no se puede sobrescribir. Funciona muy bien.