Come integrare output di generazione da un repo git in un altro

Question

Sto lavorando su un 2 progetti che sono memorizzati in 2 repo git Progetto1 e Progetto2

Project1 è un progetto javascript. Ha un proprio repository (ad esempio https://github.com/gandra/project1.git)
Project2 è un progetto java maven. Essa ha la sua pronti contro termine (ad esempio https://github.com/gandra/project2.git)

Ecco un flusso di lavoro corrente che io voglio migliorare:

1. Conferma modifiche in un Project1 e spingerlo a origine
2. Run grugnito in un Project1. Questo genera directory Project1/build
3. Copiare manualmente Project1/costruire contenuto in Progetto2/libs/project1-lib
4. Conferma modifiche (Progetto2/libs/project1-lib) in Project2
5. Runk Jenkins creare e distribuire

Desidero in qualche modo evitare il passaggio 3 (copia manuale di Project1/build contenuto nella directory Project2/libs/project1-lib) Ho pensato di integrare Project1 in Project2 come sottostruttura ma il problema con questo approccio è che lo si fa ottiene tutta la struttura di directory Project1 in Project2/libs/project1-lib e voglio solo prendere la sottodirectory o f a Project1 (Project1/build/*)

Qualche nota importante: Project1 cambia si verifica solo nel proprio repo (https://github.com/gandra/project1.git) e questo cambiamento deve essere propagato a Progetto2. Quindi non c'è nessun aggiornamento da Progetto1 Progetto2/libs/project1-lib In altre parole:
- impegna in Project1 effetto Project2
- impegna in Progetto2 non colpisce Project1

Answer 1

Ok Ricapitoliamo i fatti più importanti qui:

1. Project2 è un progetto Maven (con la confezione di guerra, probabilmente, dal momento che si distribuirlo).
2. Project2 dipende da Project1 in un modo che si aspetta la sua uscita a costruire su un percorso Project2/libs/project1-lib

A mio parere si basa (anche buils parziali) non sono destinate ad essere sotto qualsiasi codice sorgente gestione, quindi non riserverei alcun percorso di Project2 come Project2/libs/project1-lib per essere sotto il git. Il plugin di guerra Maven ha questa bella funzione maven-war-plugin-overlays. Quindi, se Project2 vedesse Project1 come dipendenza di maven con il tipo war di packaginig ad es.

<dependencies> 
    ... 
    <dependency> 
     <groupId>your.group.id</groupId> 
     <artifactId>project1</artifactId> 
     <version>1.0-SNAPSHOT</version> 
     <type>war</type> 
     <scope>runtime</scope> 
    </dependency> 
    ... 
    </dependencies> 

, non avrebbe dovuto fare qualsiasi affrontare in Progetto2/librerie/location project1-lib, perché che Maven fare per voi in fase di packaing. Ma per fare questo, devi installare artefatto di guerra del tuo Project1 nel tuo nesso. Ci sono un paio di soluzioni qui:

Soluzione 1)

1. Fare Project1 di essere pienamente progetto Maven, e rendere l'uscita sicuri di costruzione finito su un ./libs/project1-lib percorso nella sua guerra. Poiché Project1 ora verrebbe creato con Maven, sarà necessario integrare lo strumento di costruzione precedente di Project1 (grunt, gulp o qualsiasi altro) che verrà chiamato da Maven in una fase precedente alla fase di packaging.

2. In Progetto2 aggiungere nuova dipendenza come questo:

   <dependency> 
       <groupId>your.group.id</groupId> 
       <artifactId>project1</artifactId> 
       <version>1.0-SNAPSHOT</version> 
       <type>war</type> 
       <scope>runtime</scope> 
   </dependency> 
   

Soluzione 2).

1. Con il tuo attuale builder di Project1, assicurati di impacchettare il tuo progetto in guerra con la seguente struttura ./libs/project1-lib. Usando lo stesso builder installa questo come artefatto di guerra sul tuo nesso (NOTA: dovresti avere pom.xml installato sul tuo nesso in modo che l'altro progetto possa fare riferimento a Progetto1) Se stai usando grunt come costruttore js per fortuna, c'è questo npm componente grunt-nexus-deployer che farà esattamente quello che ho descritto qui.
2. come per Soluzione 1) ...

Spiegazione:

Quando spingete le modifiche di Project1 vostra CI attiverà lavoro che installerà project1-1.0-SNAPSHOT.war sul tuo Nexus dopo che questo è stato fatto, il job CI per Project2 verrà attivato e avrà tutto il necessario per la costruzione di project2.

NOTA: In entrambe le soluzioni, eliminare Project2/libs/project1-lib gerarchia, in quanto non più utilizzato ...

EDIT:

Per la soluzione 2) forse si dovrebbe usare al posto di grunt-maven-tasksgrunt-nexus-deployer perché ha più opzioni ed è più adatto.

Answer 2

Se controlli il server Git sei utilizzando, quindi è possibile realizzare ciò che stai chiedendo utilizzando uno post-receiveserver-side hook.

Tuttavia, non posso fare a meno di pensare che ci dovrebbe essere un approccio migliore rispetto al passaggio da Project1 a Project2. È ovvio che Project1 è la dipendenza di Project2. Sono più abituati alla manipolazione dipendenze il modo in cui lo fanno con Maven e Gradle:

• Avere il tool di creazione (ad esempio Gradle) per Project1 pubblicare i manufatti di build in un repository costruzione manufatto (ad esempio Artifactory).
• Lo strumento di compilazione per Project2 consente di estrarre le risorse più recenti dal repository degli artefatti di build, se necessario.

I vantaggi che vedo in questo approccio sono:

• Project1 è indipendente dalla Progetto2. Poiché Project2 richiede Project1 (e non viceversa), non dovrebbe essere responsabilità di Project1 mantenere aggiornato Project2.
• Project2 ha il controllo su come consuma Project1. Ad esempio, si è liberi di bloccare la dipendenza in una determinata versione di Project1 (ad esempio perché Project1 è attualmente interrotto e si desidera continuare a sviluppare Project2 senza attendere la correzione).
• Non stai inquinando i commit di Project2 con modifiche non correlate all'origine di Project2. Se ogni volta che Project1 viene aggiornato, ottieni un nuovo commit in Project2, abbastanza presto ti renderà la vita difficile quando si tratta di unire, ridimensionare, bisecare o qualsiasi altra cosa che normalmente devi fare.

Gli svantaggi si trovano principalmente nei requisiti di infrastruttura (all'improvviso è necessario un altro server) e nella scelta e configurazione degli strumenti di compilazione. Quando si tratta di Java, consiglierei Gradle a mani basse per lo strumento di costruzione e Artifactory per il repository di artefatto di build. Ma hai detto che il tuo Project1 è Javascript e non ho lavorato in quell'ecosistema, quindi non ho buoni consigli lì.

Modifica: ho appena realizzato che ho confuso Project1 e Project2. La domanda dice Project2 consuma Project1 e la mia risposta iniziale è stata scritta come se Project1 consumasse Project2. L'ho risolto ora, per evitare confusione.

Answer 3

Hai considerato Gradle invece di Maven?

https://blog.oio.de/2014/10/24/handling-javascript-dependencies-with-gradle/

Answer 4

Cosa ha detto Vojislav è corretto. La costruzione dei due progetti (nel modo in cui l'hai descritta) dovrebbe essere disaccoppiata. Se il prodotto finale ha bisogno di entrambi i componenti, allora è il lavoro dello strumento di costruzione (jenkins) per comporre l'applicazione. I due progetti dovrebbero essere abbastanza agnostici l'uno dell'altro.

Non ho usato Jenkins tra un po ', ma in Bamboo avrei un compito chiamato BuildProduct che avrebbe due compiti (Build Project 1) e (Build Project 2) dove l'edificio del Progetto 2 avrebbe usato il risultato della prima build (il JS costruito).