Come prevenire la sovrascrittura di artefatti rilasciati (versioni non snapshot) nel repository Maven on Hudson

Question

Descrizione del problema

Si consideri il caso Maven viene utilizzato on Hudson.

Ora qualcuno ha eseguito il checkout di un progetto, ha modificato alcuni file ma ha utilizzato accidentalmente lo stesso id artefatto e il numero di versione (non istantanea).

Lui/Lei quindi ha costruito questo progetto su hudson e ha fatto l'installazione di maven. L'artefatto modificato è ora in hudson .m2. Qualsiasi altro progetto che dipende da esso sarà costruito con artefatto modificato. Nessuno lo trova se la compilazione non fallisce. Anche se l'artefatto corretto risiede nel repository centrale, non viene mai usato perché uno modificato viene prelevato da .m2 quando hudson inizia a costruire.

Quindi sto cercando un modo per prevenire questo errore umano accidentale.

1. In ogni caso per revocare le autorizzazioni di installazione di Maven su versioni non di istantanee (artefatti rilasciati) su hudson?
2. Un modo per confrontare i checksum di .m2 in hudson e su nel repository centrale remoto in modo che gli errori di checksum possano generare avvisi o errori di compilazione?

Ho già controllato che non è possibile forzare l'aggiornamento delle versioni di non snapshot dal repository centrale poiché sono destinate a essere immutabili.

L'eliminazione del repository centrale o l'utilizzo di un repository separato per ogni lavoro su hudson comporterà rispettivamente un aumento dei tempi di build di spazio su disco &.

Qualsiasi aiuto sarebbe apprezzato.

Answer 1

Non c'era modo diretto per risolvere questo ma abbiamo risolto questo inderctly scrivendo un cron-job che passa ogni cinque minuti e tutti i segni delle jar che sono NON-SNAPSHOT letti solo nel repository locale di Hundson. In questo modo, quando un progetto in Hudson tenta di sovrascriverlo, my mvn install o mvn deploy fallisce nel sovrascrivere gli artefatti mentre sono in sola lettura.

Eventuali nuovi artefatti da decifrare possono essere facilmente scritti. Una volta scritto nei prossimi cinque minuti, lo script li contrassegna come di sola lettura.

Ecco il codice per lo script 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 

registrazione viene gestito anche per vedere che tutti gli artefatti sono stati contrassegnati come rilasciato solo.

Answer 2

Non penso che si possa trovare un modo per impedire a un'installazione di sovrascrivere un artefatto. Un server di repository dovrebbe avere un'impostazione per impedire la distribuzione di una risorsa di aggiornamento aggiornata. Vedere, ad esempio, "How do I disable artifact redeployment" per Nexus.

Answer 3

Ecco come gestiamo le versioni nel nostro progetto:

Lavoriamo su una versione SNAPSHOT. Su Jenkins, abbiamo un lavoro Fast Build che genera e verifica questa applicazione, ma fallisce se la versione è non a SNAPSHOT. Questo è fatto da un custom enforcer (questo è l'opposto di require release version enforcer).

Quando vogliamo fare un rilascio, usiamo un lavoro Jenkins per questo. Utilizzando parameterized build e Maven release plugin, la persona responsabile della versione indicherà solo la versione della versione (la versione stabile), la successiva versione SNAPSHOT e il nome del tag SCM. Pertanto, solo Jenkins definirà una versione stabile e gli sviluppatori lavoreranno sempre su un codice SNAPSHOT.

Ma ovviamente questo non impedisce agli sviluppatori di realizzare ciò che vuole sul proprio computer locale. Ma consideriamo sempre un posto affidabile: il server Jenkins.Funziona sulla mia macchina è mai una buona risposta a un problema; o)

Answer 4

Questo problema viene risolto configurando il repository Maven (ad esempio Nexus, Artifactory) da non consentire la sovrascrittura dei repository di rilascio. In Nexus abbiamo un repository per SNAPSHOT e uno per le versioni. Il repository SNAPSHOT consente la sovrascrittura. Ma il repository di release non consente la sovrascrittura. Questa è solo una semplice funzione di checkbox in Nexus per quel repository. Una volta che una versione di rilascio viene inserita nel repository, non può essere sovrascritta. Funziona molto bene.