Come utilizzare Gitlab CI per creare un progetto Java Maven?

Question

Non ho sperimentato alcun successo, sto eseguendo un Gitlab ospitato su Linux e sto cercando di capire come funziona la CI.

In base alla documentazione Gitlab è sufficiente creare un file .gitlab-ci.yml, l'implementazione Gitlab di Travis-CI. Ora dal suo aspetto si può ottenere molto con lo .gitlab-ci.yml, ma molta della documentazione fa riferimento a Ruby e ad altre lingue. Nulla è detto su come costruire progetti Java Maven.

Come posso creare una semplice applicazione in Java? Posso usare il runner condiviso, o dovrei usare un corridore specifico, in quel caso quale o quale implementazione del runner dovrei scegliere: ssh, docker o shell? Quindi, cosa devo inserire nel file .gitlab-ci.yml almeno per costruire il progetto con Maven?

Answer 1

La documentazione descrive la sintassi YAML utilizzata per controllo poggi:

• https://gitlab.com/help/ci/yaml/README.md

Allora, perché non provare a partire con il seguente ?:

job1: 
    script: "mvn package" 

Presumibilmente questo funzionerà solo se Maven è già installato, quindi avrai bisogno di un runner che supporti questo.

Non ho usato GitLab ma lo documentation suggerisce che è possibile personalizzarlo ulteriormente per utilizzare lo official Maven Docker image per eseguire le build. Sembra molto interessante, ma acconsento che la documentazione manchi di un esempio Java.

Answer 2

Register a Docker runner e utilizzare uno dei official Maven Docker images, per esempio, maven:3-jdk7 nel file .gitlab-ci.yml:

image: maven:3-jdk-7 

build: 
    script: "mvn install -B" 

Annotare il -Bflag, che è raccomandato per l'uso non interattivo.

Per quanto ho capito, non importa se il corridore è condiviso o specifico.

Answer 3

Io uso questo comando, ma in generale la documentazione su Java/Maven costruisce sembra abbastanza raro

maven-package: 
    script: "mvn install -B" 

Answer 4

Vorrei aggiungere po 'di informazioni qui ragazzi. Per prima cosa chiariamo una certa confusione riguardo al corridore condiviso e specifico.

Shared Runner: Come il suo suono nome, i corridori sono condivise le istanze del flusso di processo di costruzione che possono essere utilizzati per eseguire i lavori di ogni singolo progetto nella propria istanza gitlab installato avendo ammessi corridori condivise opzione abilitata. Per farlo ovviamente occorrono i diritti amministrativi. Come da documentazione gitlab corrente, solo l'uso con i diritti amministrativi è in grado di definire il corridore condiviso.

corridore specifico Questo tipo di corridore esegue lavori di un solo progetto.

Inoltre, questi sono alcuni punti importanti da tenere a mente quando si sceglie il corridore per i propri progetti.

1. Runners condivise sono utili per i lavori che hanno esigenze simili, tra più progetti. Piuttosto che avere più corridori inattivi per molti progetti, puoi avere un singolo o un numero limitato di corridori che gestiscono più progetti. Ciò semplifica la manutenzione e l'aggiornamento dei corridori per un insieme comune di progetti.
2. I corridori specifici sono utili per lavori con requisiti speciali o per progetti con una richiesta specifica. Se un lavoro ha determinati requisiti, è possibile impostare il corridore specifico tenendo presente questo, senza doverlo fare per tutti i corridori. Ad esempio, se si desidera distribuire un determinato progetto, è possibile impostare un corridore specifico per avere le credenziali corrette per questo.

Ora per selezionare l'esecutore di destra per il progetto, è molto importante avere una panoramica di tutti gli esecutori disponibili per gitlab runner. Gitlab ha reso questo lavoro semplice per noi fornendo una buona documentazione oltre here spiegando quali sono le diverse opzioni che otterrete con diversi esecutori.

Se volete sapere di più su corridori e diversi esecutori, vorrei suggerire di iniziare con questo articolo, Gitlab Runner

Answer 5

ho speso una discreta quantità di tempo cercando di creare i nostri progetti Java su Gitlab CI. L'ho fatto funzionare con un certo grado di successo. Come menzionato da rolve, la soluzione più semplice è quella di utilizzare un'immagine dal repository ufficiale: https://hub.docker.com/_/maven

Tuttavia, abbiamo un proxy aziendale che causa il timeout delle richieste dei miei build durante il recupero delle dipendenze del progetto. Ho provato molte soluzioni e finalmente ho trovato questo post: https://gitlab.com/gitlab-org/gitlab-ce/issues/15167.

Il post stesso riguarda la configurazione di Maven per memorizzare le dipendenze scaricate in un repository locale a cui è possibile accedere tra le build. L'idea è che puoi scrivere un file di configurazione di Maven locale in .gitlab-ci.yml per impostare la directory della cache e il tuo proxy.

before_script: 
    -echo '<settings 
      xmlns="http://maven.apache.org/SETTINGS/1.0.0" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
      xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
      https://maven.apache.org/xsd/settings-1.0.0.xsd"> 
      <localRepository>/cache/.m2</localRepository> 
      <proxies> 
       <proxy> 
        <active>true</active> 
        <protocol>'$PROXY_PROTOCOL'</protocol> 
        <host>'$PROXY_HOST'</host> 
        <port>'$PROXY_PORT'</port> 
       </proxy> 
      </proxies> 
     </settings>' > $HOME/.m2/settings.xml 

build_debug1: 
    stage: build 
    script: "echo $PROXY_HOST" 

build_debug2: 
    stage: build 
    script: "cat $HOME/.m2/settings.xml" 

build_maven: 
    stage: build 
    script: "mvn $MAVEN_CLI_OPTS package" 
    artifacts: 
    paths: 
     - target/*.jar 

deploy_debug1: 
    stage: package 
    script: "ls target/" 

Si noti che i lavori di debug di build sono solo per vedere se le impostazioni del proxy sono state iniettate correttamente. Puoi impostare le variabili di ambiente proxy come segreti usando Gitlab andando su Progetto -> Impostazioni -> Condutture CI/CD -> Variabili segrete.

L'ultimo lavoro deploy_debug è vedere cosa è stato generato nella directory di destinazione.