Jak wykorzystać Gitlab CI do zbudowania projektu Java Maven?

Question

Eksperymentowałem bez żadnego sukcesu, używam Gitlab'a hostowanego na Linuksie i próbując zrozumieć moją funkcjonalność CI.

Zgodnie z dokumentacją Gitlab, wystarczy utworzyć plik .gitlab-ci.yml, implementację Travis-CI w Gitlab. Teraz z jego wyglądu można wiele osiągnąć dzięki .gitlab-ci.yml, ale wiele dokumentacji odwołuje się do Rubiego i innych języków. Nic nie mówi się o tym, jak budować projekty Java Maven.

Jak mogę zbudować prostą aplikację w Javie? Czy mogę korzystać ze współdzielonego runnera, czy też powinienem używać określonego runnera, w takim przypadku, jaki lub jaki wariant wdrożenia powinien wybrać: ssh, docker lub shell? W takim razie, co powinienem umieścić w pliku .gitlab-ci.yml co najmniej w celu zbudowania projektu z Mavenem?

Answer 1

Dokumentacja opisuje składnia YAML używany do kontroli buduje:

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

Więc dlaczego nie zacząć od następującej ?:

job1: 
    script: "mvn package" 

Przypuszczalnie będzie działać tylko wtedy, gdy Maven jest już zainstalowany, więc będziesz potrzebować runner, który obsługuje to.

Nie użyłem GitLab, ale documentation sugeruje, że można go dalej dostosować, aby użyć wersji official Maven Docker image do wykonania kompilacji. Wygląda bardzo interesująco, ale zgadzam się, że w dokumentacji brakuje przykładu Java.

Answer 2

Register a Docker runner i używać jednego z official Maven Docker images, np maven:3-jdk7 w pliku .gitlab-ci.yml:

image: maven:3-jdk-7 

build: 
    script: "mvn install -B" 

Zanotować -Bflag, który jest zalecany dla nieinterakcyjnym użytkowania.

O ile rozumiem, nie ma znaczenia, czy biegacz jest wspólny czy konkretny.

Answer 3

Używam tego polecenia, ale w ogóle dokumentację java/Maven buduje wydaje się dość rzadko

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

Answer 4

chciałbym dodać trochę informacji o facetów. Najpierw rozwińmy pewne zamieszanie dotyczące wspólnego i konkretnego biegacza.

Shared Runner: jak sama nazwa dźwięku, wspólne biegacze są przypadki przebiegu procesu kompilacji, które mogą być używane do wykonywania zadań z każdego projektu w zainstalowanym gitlab przykład mającego domowe wieloosobowe biegaczy opcja włączona. Aby to zrobić, musisz mieć prawa administracyjne. Zgodnie z aktualną dokumentacją gitlab używanie tylko z uprawnieniami administratora jest w stanie zdefiniować współdzielonego runnera.

konkretny biegacz Ten rodzaj biegacza wykonuje zadania tylko jednego projektu.

Te kilka ważnych punktów należy wziąć pod uwagę przy wyborze biegacza do swoich projektów.

1. Shared Runners są przydatne do zadań, które mają podobne wymagania, między wieloma projektami. Zamiast wielu biegaczy pracujących na biegu jałowym dla wielu projektów, możesz mieć jedną lub małą liczbę biegaczy, którzy obsługują wiele projektów. Ułatwia to konserwację i aktualizację biegaczy dla wspólnego zestawu projektów.
2. Określeni biegacze są przydatni dla zadań, które mają specjalne wymagania lub dla projektów o określonym zapotrzebowaniu. Jeśli praca ma określone wymagania, możesz ustawić konkretnego biegacza, pamiętając o tym, nie robiąc tego dla wszystkich biegaczy. Na przykład, jeśli chcesz wdrożyć pewien projekt, możesz skonfigurować określonego biegacza, aby uzyskać odpowiednie poświadczenia.

Teraz, aby wybrać odpowiedni executor dla projektu, jego bardzo ważne jest, że mamy widok ptaka na wszystkie dostępne executory dla programu gitlab runner. Gitlab uczynił tę pracę łatwą dla nas, dostarczając ładną dokumentację ponad here wyjaśniającą, jakie są różne opcje, które otrzymasz z różnymi executorami.

Jeśli chcesz wiedzieć więcej o biegaczy i różnych wykonawców, proponuję zacząć od tego artykułu, Gitlab Runner

Answer 5

Spędziłem sporo czasu próbując skonfigurować nasze projekty Java na Gitlab CI. Pracowałem z pewnym powodzeniem. Jak wspomniano w Rolve, najprostszym rozwiązaniem jest użycie obrazu z oficjalnego repo: https://hub.docker.com/_/maven

Mamy jednak korporacyjny serwer proxy, który powodował, że moje kompilacje otrzymują żądania przekroczenia limitu czasu podczas pobierania zależności projektu. Próbowałem wielu rozwiązań i natknąłem się na ten post: https://gitlab.com/gitlab-org/gitlab-ce/issues/15167.

Sam słupek ma na celu skonfigurowanie narzędzia do buforowania pobranych zależności w lokalnym repo, do którego można uzyskać dostęp w kompilacjach. Chodzi o to, że można zapisać lokalny plik konfiguracyjny maven przez .gitlab-ci.yml, aby skonfigurować katalog pamięci podręcznej i serwer 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/" 

Zauważ, że zadania debugowania kompilacji służą jedynie do sprawdzenia, czy ustawienia proxy zostały poprawnie wprowadzone. Możesz ustawić zmienne środowiskowe proxy jako tajemnice za pomocą Gitlab, przechodząc do Project -> Ustawienia -> CI/Pipeline CD -> Secret Variables.

Ostatnie zadanie deploy_debug polega na sprawdzeniu, co zostało wygenerowane w katalogu docelowym.