Maven multi-module distribuire nel repository solo dopo test di unità efficaci

Question

Domanda: Qual è la soluzione migliore per eseguire una 'mvn deploy' in modo tale che la parte di deploy venga eseguita solo dopo che tutti i test di unità hanno avuto esito positivo e nessuna fase di elaborazione è stata duplicata?

Speravo che la semplice risposta fosse: Esegui il comando maven 'x' (o usa un flag) in modo tale che la distribuzione possa essere eseguita senza richiamare gli obiettivi precedenti nel ciclo di vita predefinito.

Purtroppo questo non sembra avere una risposta semplice. Ho incluso i dettagli sul percorso che ho seguito fino ad ora.

abbiamo le seguenti tre requisiti:

• Eseguire l'esperto di distribuire obiettivo di implementare tutti gli artefatti multi-modulo ad un repository remoto.
• Distribuire solo se passano TUTTI i test di unità su tutti i progetti.
• Non ripetere alcuna elaborazione.

Abbiamo iniziato con semplicemente "mvn Deploy pulita", tuttavia abbiamo notato un paio di problemi:

• l'accumulo sarebbe fermata prima di aver completato tutti i test di unità :: quindi abbiamo aggiunto il --fail-a- flag di fine
• L'obiettivo di implementazione verrebbe eseguito su tutti i moduli che avevano avuto successo.

Questo risulta in uno stato "danneggiato" in cui il repository remoto può disporre solo di un'implementazione parziale (se ci sono moduli con errori successivamente nella generazione).

Abbiamo guardato 3 diverse soluzioni:

1. gestione temporanea i manufatti prima di distribuire :: questo è stato determinato per essere troppo pesante per un processo completamente automatizzato.
2. Utilizzare un profilo per sovrascrivere il ciclo di vita predefinito in modo che 'mvn deploy -Pci-deploy' possa essere eseguito senza richiamare alcuno degli obiettivi precedenti: ha funzionato ed è stato veloce, ma è ovviamente un approccio non convenzionale.
3. Semplicemente eseguire 'pacchetto mvn clean' e solo se è riuscito ad eseguire 'mvn deploy': sembra funzionare e sembra richiedere solo un piccolo successo quando gli obiettivi vengono richiamati (anche se alcuni di essi sono abbastanza intelligenti da non rielaborare uno spazio di lavoro immutato)

mi pongo questa domanda per la comunità con i dettagli di sfondo che ho fornito per determinare se v'è un approccio migliore o un forte parere per quanto riguarda (potenzialmente) facendo una delle seguenti richieste:

• Un nuovo obiettivo di distribuzione che può essere eseguito separatamente e separatamente da tutti gli altri obiettivi del ciclo di vita con l'expecta che: tutti i passi precedenti sono già stati eseguiti e che eseguirà la distribuzione identicamente a "mvn deploy"
• un flag nell'obiettivo di distribuzione che disabiliterebbe effettivamente gli obiettivi precedenti.

un po 'più fuori dalla scatola e sicuramente contro la convenzione corrente:

• una bandiera che avrebbe detto Maven per eseguire il [unità] obiettivo di prova per tutti i moduli prima di procedere.

Note:

• Stiamo usando Jenkins, ma per gli scopi di questa domanda l'ambiente CI non è la complicanza.
• Ho provato l'obiettivo 'mvn deploy: deploy', ma aveva un numero di errori non chiari.
• Non ho considerato i test di integrazione come parte dei requisiti.

---

aggiornamento 8/20/2013

Ho testato il plugin Deploy differita e determinato che lo strumento ha funzionato come previsto, ma ha avuto modo di tempo.

Per la nostra base di codice:

• mvn Deploy pulita: per tutti gli obiettivi eseguiti in 2:44
• mvn clean install 'differita implementare-plugin': per tutti gli obiettivi eseguite in 15 min
• mvn clean package; mvn distribuire -PCI-distribuire un profilo di generazione personalizzata che disabilita gli obiettivi precedenti eseguiti:
  • per tutti gli obiettivi (tra cui Deploy): 04:30
  • distribuire solo: 1:45
• mvn pulita pacchetto; mvn distribuire -Dmaven.test.skip = true sulla stessa area di lavoro eseguito:
  • per tutti gli obiettivi (tra cui Deploy): solo 4:40
  • Deploy: 1:54

Il pacchetto clean seguito dalla distribuzione saltando i test viene eseguito più rapidamente rispetto alla distribuzione posticipata e ha raggiunto il nostro desiderio di ritardare la distribuzione fino a dopo il completamento dei test.

Sembra esserci un minor tempo per il momento in cui il ciclo di vita della distribuzione esegue ed esce da ciascuno degli obiettivi precedenti (processo, compilazione, test, pacchetto, ecc.). Tuttavia l'unica alternativa è quella di hackerare un'esecuzione non standard, che consente solo di risparmiare 10 secondi.

Answer 1

C'è una nuova risposta ora. Dalla versione 2.8 del plugin maven deploy c'è un modo per farlo in modo "nativo". Vedi the jira issue per i dettagli.

Fondamentalmente è necessario forzare almeno v2.8 del plugin

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-deploy-plugin</artifactId> 
    <version>2.8</version> 
</plugin> 

e utilizzare il nuovo parametro deployAtEnd. più informazioni here. Questa impostazione di solito va di pari passo con installAtEnd del plug-install maven

Answer 2

Due cose.

1. Disabilitare tutte le fasi precedenti non lo vedo come opzione.È una caratteristica di base di Maven, dovresti alterare il ciclo di vita standard quindi dubito fortemente che qualcuno possa implementare qualcosa in un plug-in per consentire a questo
2. Dato che hai detto di usare Jenkins, c'è un'impostazione in jenkins specificatamente per il caso di la distribuzione alla fine di garantire che il repo non è in uno/stato intermedio corrotto

in "post-costruire azioni"

distribuire i manufatti in un repository Maven. Rispetto alla distribuzione mvn standard , questa funzione consente di distribuire gli artefatti dopo lo per confermare che l'intera compilazione ha esito positivo. Ciò impedisce un tipico problema in Maven, in cui alcuni moduli vengono distribuiti prima che un errore critico venga rilevato in un secondo momento lungo la strada, rendendo incoerente lo stato del repository. Si noti che indipendentemente da questa configurazione, è sempre possibile tornare manualmente a Jenkins e distribuire le risorse precedenti a qualsiasi repository di propria scelta, dopo il fatto. Per utilizzare questa funzione non è necessario disattivare l'archiviazione degli artefatti automatici.

non ho mai usato questo quindi non posso confermare se funziona, so solo che è lì per questo particolare caso d'uso

Answer 3

In alternativa, ho trovato anche questo http://code.google.com/p/maven-deferred-deploy-plugin/

Un plug-in maven che scorre tutti i progetti in un reattore e esegue una distribuzione su ogni progetto singolarmente. Può essere utilizzato per produrre una build quasi atomica per un reattore rimandando la distribuzione degli artefatti fino al completamento della fase di installazione.

Suoni molto simili a quello che stavi chiedendo. Continuo a pensare che l'altra mia risposta sia più semplice da implementare dal momento che usi Jenkins, basta selezionare la casella di controllo