Innstilling av GitLab CI for opplasting av java-prosjekt til maven central

Denne artikkelen er rettet mot java-utviklere som har behov for å raskt publisere produktene sine i sonatype og/eller maven central ved hjelp av GitLab. I denne artikkelen vil jeg forklare hvordan man konfigurerer gitlab-runner, gitlab-ci og maven-plugin for å løse denne oppgaven.

Forutsetninger:

• Sikker lagring av mvn og GPG-nøkler.
• Sikker kjøring av offentlige CI-oppgaver.
• Opplasting av artefakter (release/snapshot) til offentlige registre.
• Automatisk sjekk av release-versjoner for publisering til maven central.
• Generell løsning for opplasting av artefakter til depotet for flere prosjekter.
• Enkelhet og brukervennlighet.

Innhold

• Generell informasjon
• Konfigurere deploy-prosjekt i GitLab
• GitLab Runner
  • Spesifikk Runner
    • Installere gitlab runner
    • Generering av GPG-nøkler
    • Konfigurere Maven
  • Delt Runner
    • Generering av GPG-nøkler
    • Konfigurere Maven
    • Deploy docker image
• GitLab CI
  • Deploy prosjekt
  • Java-prosjekt
• Konfigurasjon av pom.xml
  • maven-install-plugin
  • maven-javadoc-plugin
  • maven-gpg-plugin
  • nexus-staging-maven-plugin
• Resultatet
  • Publisering av snapshot-versjon
  • Publisering av release-versjon
• Konklusjon

Generell informasjon

• En detaljert beskrivelse av mekanismen for publisering av artefakter til Maven Central via Sonatype OSS Repository Hosting Service er allerede beskrevet i denne artikkelen av brukeren Googolplex, så jeg vil referere til denne artikkelen der det er nødvendig.
• Først registrerer vi oss i Sonatype JIRA og oppretter en billett for å åpne depotet (les mer i seksjonen Opprett billett i Sonatype JIRA). Etter åpningen av depotet vil et par brukernavn/passord fra JIRA (heretter Sonatype-kontoen) bli brukt til å laste opp artefakter til Sonatype nexus.
• Prosessen for å generere GPG-nøkkel er beskrevet ganske tørt. For mer detaljert informasjon, se seksjonen Konfigurere GnuPG for signering av artefakter
• Hvis du bruker Linux-konsollen for å generere GPG-nøkler (gnupg/gnupg2), må du installere rng-tools for å generere entropi. Ellers kan nøkkelgenereringen ta veldig lang tid.
• Lagringstjenester for offentlige GPG-nøkler
  • http://keys.gnupg.net
  • http://pool.sks-keyservers.net
  • http://keyserver.ubuntu.com

Til innhold

Konfigurere deploy-prosjekt i GitLab

• Først må du opprette og konfigurere et prosjekt som skal lagre pipeline for distribusjon av artefakter. Mitt prosjekt har jeg kalt enkelt og beskrivende — deploy
• Etter opprettelsen av depotet, må tilgangen til å endre depotet begrenses.
  Gå til prosjektet -> Innstillinger -> Repository -> Beskyttede grener. Fjern alle regler og legg til en eneste regel med Wildcard * som gir push- og merge-rett kun for brukere med rollen Maintainers. Denne regelen vil gjelde for alle brukere både i dette prosjektet og i gruppen prosjektet tilhører.
  
• Hvis det er flere maintainere, vil det beste være å begrense tilgangen til prosjektet generelt.
  Gå til prosjektet -> Innstillinger -> Generelt -> Synlighet, prosjektfunksjoner, tillatelser og sett Prosjektets synlighet til verdien Privat.
  Jeg har prosjektet mitt offentlig tilgjengelig, siden jeg bruker min egen GitLab Runner og kun jeg har tilgang til å endre depotet. Jeg ønsker selvsagt ikke å eksponere privat informasjon i offentlige pipeline-logger.
• Strengere regler for endringer i depotet
  Gå til prosjektet -> Innstillinger -> Repository -> Push-regler og aktiver flaggene for Committer-restriksjon og Sjekk om forfatteren er en GitLab-bruker. Jeg anbefaler også å konfigurere signering av commits, og aktiver flagget Forsøk å avvise usignerte commits.
• Deretter må du konfigurere en trigger for å starte oppgaver
  Gå til prosjektet -> Innstillinger -> CI / CD -> Pipeline-triggere og opprett en ny trigger-token
  Denne tokenen kan legges direkte til de generelle konfigurasjonsvariablene for prosjektgruppen.
  Gå til gruppen -> Innstillinger -> CI / CD -> Variabler og legg til variabelen DEPLOY_TOKEN med trigger-token som verdi.

Til innhold

GitLab Runner

I denne delen beskrives konfigurasjonen for å kjøre oppgaver på deploy ved hjelp av egne (Specific) og offentlige (Shared) runner.

Spesifikk Runner

Jeg bruker egne runners, da det først og fremst er praktisk, raskt og billig.
For runner anbefaler jeg en Linux VDS med 1 CPU, 2 GB RAM, 20 GB HDD. Kostnaden er ~3000₽ i året.

Min runner

For runneren tok jeg en VDS med 4 CPU, 4 GB RAM, 50 GB SSD. Den kostet ~11000₽ og jeg har ikke angret en gang.
Jeg har totalt 7 maskiner. 5 hos Aruba og 2 hos Ihor.

Så vi har en runner. Nå skal vi konfigurere den.
Logg inn på maskinen via SSH og installer java, git, maven, gnupg2.

Til innhold

Installer gitlab runner

• Opprett en ny gruppe runner

  sudo groupadd runner

• Opprett en katalog for maven-cache og gi gruppe-rettigheter runner
  Dette punktet kan hoppes over hvis du ikke planlegger å kjøre flere runners på én maskin.

  mkdir -p /usr/cache/.m2/repository
  chown -R :runner /usr/cache
  chmod -R 770 /usr/cache

• Opprett bruker gitlab-deployer og legg den til gruppen runner

  useradd -m -d /home/gitlab-deployer gitlab-deployer
  usermod -a -G runner gitlab-deployer

• Legg til følgende linje i filen /etc/ssh/sshd_config neste linja

  AllowUsers root@* gitlab-deployer@127.0.0.1

• Laster opp igjen sshd

  systemctl restart sshd

• Setter passord for bruker gitlab-deployer (kan være enkelt, da det er et begrensning for localhost)

  passwd gitlab-deployer

• Installerer GitLab Runner (Linux x86-64)

  sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
  sudo chmod +x /usr/local/bin/gitlab-runner
  ln -s /usr/local/bin/gitlab-runner /etc/alternatives/gitlab-runner
  ln -s /etc/alternatives/gitlab-runner /usr/bin/gitlab-runner

• Gå til nettstedet gitlab.com -> deploy-project -> Innstillinger -> CI/CD -> Runners -> Spesifikke Runners og kopier registreringstoken

Skjermbilde

• Registrerer runner

  gitlab-runner register --config /etc/gitlab-runner/gitlab-deployer-config.toml

Prosessen

Runtime platform arch=amd64 os=linux pid=17594 revision=3001a600 version=11.10.0
Kjører i systemmodus.
Vennligst skriv inn gitlab-ci koordinator URL (f.eks. https://gitlab.com/):
https://gitlab.com/
Vennligst skriv inn gitlab-ci token for denne runner:
REGISTRATION_TOKEN
Vennligst skriv inn gitlab-ci beskrivelse for denne runner:
[ih1174328.vds.myihor.ru]: Deploy Runner
Vennligst skriv inn gitlab-ci tags for denne runner (kommaseparert):
deply
Registrerer runner... lyktes                     runner=ZvKdjJhx
Vennligst skriv inn utføreren: docker-ssh, parallels, virtualbox, docker-ssh+machine, kubernetes, docker, ssh, docker+machine, shell:
shell
Runner registrert med suksess. Føl deg fri til å starte den, men hvis den allerede kjører, skal konfigurasjonen automatisk lastes på nytt!

• Sjekker at runner er registrert. Gå til nettstedet gitlab.com -> deploy-project -> Innstillinger -> CI/CD -> Runners -> Spesifikke Runners -> Runners aktivert for dette prosjektet

Skjermbilde

• Legger til separat tjeneste /etc/systemd/system/gitlab-deployer.service

  [Unit]
  Description=GitLab Deploy Runner
  After=syslog.target network.target
  ConditionFileIsExecutable=/usr/local/bin/gitlab-runner
  [Service]
  StartLimitInterval=5
  StartLimitBurst=10
  ExecStart=/usr/local/bin/gitlab-runner "run" "--working-directory" "/home/gitlab-deployer" "--config" "/etc/gitlab-runner/gitlab-deployer-config.toml" "--service" "gitlab-deployer" "--syslog" "--user" "gitlab-deployer"
  Restart=always
  RestartSec=120
  [Install]
  WantedBy=multi-user.target

• Starter tjenesten.

  systemctl enable gitlab-deployer.service
  systemctl start gitlab-deployer.service
  systemctl status gitlab-deployer.service

• Sjekker at runner er startet.

Eksempel

Til innhold

Generering av GPG-nøkler

• Fra denne maskinen logger vi på via ssh med brukeren gitlab-deployer (dette er viktig for å generere GPG-nøkkel)

  ssh gitlab-deployer@127.0.0.1

• Genererer nøkkel ved å svare på spørsmålene. Jeg brukte mitt eget navn og e-post.
  Husk å spesifisere passord for nøkkelen. Denne nøkkelen vil bli brukt for å signere artefakter.

  gpg --gen-key 

• Sjekk

  gpg --list-keys -a
  /home/gitlab-deployer/.gnupg/pubring.gpg
  ----------------------------------------
  pub   4096R/00000000 2019-04-19
  uid                  Petruha Petrov 
  sub   4096R/11111111 2019-04-19

• Laster opp vår offentlige nøkkel til nøkkelserveren

  gpg --keyserver keys.gnupg.net --send-key 00000000
  gpg: sending key 00000000 to hkp server keys.gnupg.net

Til innhold

Konfigurere Maven

• Logger inn med brukeren gitlab-deployer

  su gitlab-deployer 

• Oppretter maven repository og lenker med cachen (ikke gjør feil)
  Dette punktet kan hoppes over hvis du ikke planlegger å kjøre flere runnere på én maskin.

  mkdir -p ~\/ .m2\/ repository
  ln -s \/ usr\/cache\/ .m2\/ repository \/ home\/ gitlab-deployer\/ .m2\/ repository

• Opprett masternøkkel

  mvn --encrypt-master-password password
  {hnkle5BJ9HUHUMP+CXfGBl8dScfFci\/mpsur\/73tR2I=}

• Opprett fil ~\/ .m2\/ settings-security.xml

  {hnkle5BJ9HUHUMP+CXfGBl8dScfFci\/mpsur\/73tR2I=}

• Krypter passordet til Sonatype-kontoen

  mvn --encrypt-password SONATYPE_PASSWORD
  {98Wv5+u+Tn0HX2z5G\/ kR4R8Z0WBgcDBgi7d12S\/ un+SCU7uxzaZGGmJ8Cu9pAZ2J}

• Opprett fil ~\/ .m2\/ settings.xml

  env
          
              true
          
          
              GPG_SECRET_KEY_PASSPHRASE
          
      
  
  
      
          sonatype
          SONATYPE_USERNAME
          {98Wv5+u+Tn0HX2z5G\/ kR4R8Z0WBgcDBgi7d12S\/ un+SCU7uxzaZGGmJ8Cu9pAZ2J}

hvor,
GPG_SECRET_KEY_PASSPHRASE — passordet til GPG-nøkkelen
SONATYPE_USERNAME — brukernavn for Sonatype-kontoen

Nå er oppsettet av runneren ferdig, vi kan gå videre til avsnittet GitLab CI

Til innhold

Delt Runner

Generering av GPG-nøkler

• Først må vi opprette en GPG-nøkkel. For dette installeres gnupg.

  yum install -y gnupg

• Generer nøkkelen mens du svarer på spørsmålene. Jeg brukte eget navn og e-post. Husk å oppgi passord for nøkkelen.

  gpg --gen-key 

• Viser informasjon om nøkkelen

  gpg --list-keys -a
  pub   rsa3072 2019-04-24 [SC] [expires: 2021-04-23]
    2D0D1706366FC4AEF79669E24D09C55BBA3FD728
  uid           [ultimate] tttemp 
  sub   rsa3072 2019-04-24 [E] [expires: none]

• Laster opp vår offentlige nøkkel til nøkkelserveren

  gpg --keyserver keys.gnupg.net --send-key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728
  gpg: sender key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 til hkp-server keys.gnupg.net

• Hent den private nøkkelen

  gpg --export-secret-keys --armor 2D0D1706366FC4AEF79669E24D09C55BBA3FD728
  -----BEGIN PGP PRIVATE KEY BLOCK-----
  lQWGBFzAqp8BDADN41CPwJ\/ gQwiKEbyA902DKw\/WSB1AvZQvV\/ ZFV77xGeG4K7k5
  ...
  =2Wd2
  -----END PGP PRIVATE KEY BLOCK-----

• Gå til prosjektinnstillinger -> Innstillinger -> CI / CD -> Variabler og lagre den private nøkkelen i variabelen GPG_SECRET_KEY
  

Til innhold

Konfigurere Maven

• Opprett masternøkkel

  mvn --encrypt-master-password password
  {hnkle5BJ9HUHUMP+CXfGBl8dScfFci\/mpsur\/73tR2I=}

• Gå til prosjektinnstillinger -> Innstillinger -> CI / CD -> Variabler og lagre i variabelen SETTINGS_SECURITY_XML følgende linjer:

  {hnkle5BJ9HUHUMP+CXfGBl8dScfFci\/mpsur\/73tR2I=}

• Krypter passordet til Sonatype-kontoen

  mvn --encrypt-password SONATYPE_PASSWORD
  {98Wv5+u+Tn0HX2z5G\/ kR4R8Z0WBgcDBgi7d12S\/ un+SCU7uxzaZGGmJ8Cu9pAZ2J}

• Gå til prosjektinnstillinger -> Innstillinger -> CI / CD -> Variabler og lagre i variabelen SETTINGS_XML følgende linjer:

  env
          
              true
          
          
              GPG_SECRET_KEY_PASSPHRASE
          
      
  
  
      
          sonatype
          sonatype_username
          {98Wv5+u+Tn0HX2z5G\/ kR4R8Z0WBgcDBgi7d12S\/ un+SCU7uxzaZGGmJ8Cu9pAZ2J}

hvor,
GPG_SECRET_KEY_PASSPHRASE — passordet til GPG-nøkkelen
SONATYPE_USERNAME — brukernavn for Sonatype-kontoen

Til innhold

Deploy docker image

• Opprett en ganske enkel Dockerfile for å kjøre oppgaver på utdeling med nødvendig versjon av Java. Nedenfor er et eksempel for alpine.

  FRA java:8u111-jdk-alpine
  RUN apk add gnupg maven git --update-cache 
  --repository http://dl-4.alpinelinux.org/alpine/edge/community/ --allow-untrusted && 
  mkdir ~/.m2/

• Vi bygger en container for prosjektet ditt

  docker build -t registry.gitlab.com/group/deploy .

• Vi autentiserer oss og laster opp containeren til registeret.

  docker login -u USER -p PASSWORD registry.gitlab.com
  docker push registry.gitlab.com/group/deploy

Til innhold

GitLab CI

Deploy prosjekt

Vi legger til filen .gitlab-ci.yml i rotmappen til deploy-prosjektet
I skriptet er det to gjensidig utelukkende oppgaver for distribusjon. Spesifikk Runner eller Delt Runner, henholdsvis.

.gitlab-ci.yml

stages:
  - deploy

Specific Runner:
  extends: .java_deploy_template
  # Oppgaven vil bli kjørt på din shell-runner
  tags:
    - deploy

Shared Runner:
  extends: .java_deploy_template
  # Oppgaven vil bli kjørt på en offentlig docker-runner
  tags:
    - docker
  # Bildet fra delen GitLab Runner -> Shared Runner -> Docker
  image: registry.gitlab.com/group/deploy-project:latest
  before_script:
    # Importerer GPG-nøkkel
    - printf "${GPG_SECRET_KEY}" | gpg --batch --import
    # Lagre maven-konfigurasjon
    - printf "${SETTINGS_SECURITY_XML}" > ~/.m2/settings-security.xml
    - printf "${SETTINGS_XML}" > ~/.m2/settings.xml

.java_deploy_template:
  stage: deploy
  # Oppgaven vil trigges hvis variabelen DEPLOY er satt til java
  only:
    variables:
    - $DEPLOY == "java"
  variables:
    # Deaktiverer kloning av det nåværende prosjektet
    GIT_STRATEGY: none
  script:
    # Tillater lagring av passord i ukryptert form
    - git config --global credential.helper store
    # Lagrer midlertidige credentials for bruker gitlab-ci-token
    # Tokenet fungerer for alle offentlige prosjekter på gitlab.com og for gruppeprosjekter
    - echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" >> ~/.git-credentials
    # Rydder opp i gjeldende katalog
    - rm -rf .* *
    # Kloner prosjektet som skal distribueres til Sonatype Nexus
    - git clone ${DEPLOY_CI_REPOSITORY_URL} .
    # Bytter til ønsket commit
    - git checkout ${DEPLOY_CI_COMMIT_SHA} -f
    # Hvis noen pom.xml inneholder parameteret autoReleaseAfterClose, avbryter vi byggingen.
    # Ellers er det risiko for å laste opp rå artefakter til maven central
    - >
      for pom in $(find . -name pom.xml); do
        if [[ $(grep -q autoReleaseAfterClose "$pom" && echo $?) == 0 ]]; then
          echo "Fil $pom inneholder forbudt innstilling: ";
          exit 1;
        fi;
      done
    # Hvis parameteret DEPLOY_CI_COMMIT_TAG er tomt, setter vi tvunget SNAPSHOT-versjon
    - >
      if [[ "${DEPLOY_CI_COMMIT_TAG}" != "" ]]; then
        mvn versions:set -DnewVersion=${DEPLOY_CI_COMMIT_TAG}
      else
        VERSION=$(mvn -q -Dexec.executable=echo -Dexec.args='${project.version}' --non-recursive exec:exec)
        if [[ "${VERSION}" == *-SNAPSHOT ]]; then
          mvn versions:set -DnewVersion=${VERSION}
        else
          mvn versions:set -DnewVersion=${VERSION}-SNAPSHOT
        fi
      fi
    # Kjør oppgaven for bygging og distribusjon av artefakter
    - mvn clean deploy -DskipTests=true

Til innhold

Java-prosjekt

I Java-prosjekter som skal lastes opp til offentlige depoter, må det legges til 2 trinn for opplasting av Release- og Snapshot-versjoner.

.gitlab-ci.yml

stages:
  - build
  - test
  - verify
  - deploy



Release:
  extends: .trigger_deploy
  # Kjør oppgaven kun på tag.
  only:
    - tags

Snapshot:
  extends: .trigger_deploy
  # Kjør oppgaven for publisering av SNAPSHOT-versjonen manuelt
  when: manual
  # Ikke kjør oppgaven hvis en tag er angitt.
  except:
    - tags

.trigger_deploy:
  stage: deploy
  variables:
    # Deaktiver kloning av det nåværende prosjektet
    GIT_STRATEGY: none
    # URL til trigger-deploy-oppgaven
    URL: "https://gitlab.com/api/v4/projects//trigger/pipeline"
    # Variabler for deploy-oppgaven
    POST_DATA: "
      token=${DEPLOY_TOKEN}&
      ref=master&
      variables[DEPLOY]=${DEPLOY}&
      variables[DEPLOY_CI_REPOSITORY_URL]=${CI_REPOSITORY_URL}&
      variables[DEPLOY_CI_PROJECT_NAME]=${CI_PROJECT_NAME}&
      variables[DEPLOY_CI_COMMIT_SHA]=${CI_COMMIT_SHA}&
      variables[DEPLOY_CI_COMMIT_TAG]=${CI_COMMIT_TAG}
      "
  script:
    # Ikke bruk cURL, siden med flaggene --fail --show-error
    # så viser det ikke svarinnholdet hvis HTTP-kodene er 400 eller høyere
    - wget --content-on-error -qO- ${URL} --post-data ${POST_DATA}

I denne løsningen har jeg gått litt lenger og bestemt meg for å bruke en CI-mal for Java-prosjekter.

Mer detaljert

Jeg har opprettet et eget prosjekt gitlab-ci hvor jeg har lagt inn CI-malen for Java-prosjekter common.yml.

common.yml

stages:
  - bygge
  - teste
  - bekrefte
  - distribuer

variables:
  SONAR_ARGS: "
  -Dsonar.gitlab.commit_sha=${CI_COMMIT_SHA} 
  -Dsonar.gitlab.ref_name=${CI_COMMIT_REF_NAME} 
  "

.build_java_project:
  stage: bygge
  tags:
    - touchbit-shell
  variables:
    SKIP_TEST: "false"
  script:
    - mvn clean
    - mvn package -DskipTests=${SKIP_TEST}
  artifacts:
    when: alltid
    expire_in: 30 dager
    paths:
      - "*\/target\/reports"

.build_sphinx_doc:
  stage: bygge
  tags:
    - touchbit-shell
  variables:
    DOCKERFILE: .indirect\/docs\/Dockerfile
  script:
    - docker build --no-cache -t ${CI_PROJECT_NAME}\/doc -f ${DOCKERFILE} .

.junit_module_test_run:
  stage: teste
  tags:
    - touchbit-shell
  variables:
    MODULE: ""
  script:
    - cd ${MODULE}
    - mvn test
  artifacts:
    when: alltid
    expire_in: 30 dager
    paths:
      - "*\/target\/reports"

.junit_test_run:
  stage: teste
  tags:
    - touchbit-shell
  script:
    - mvn test
  artifacts:
    when: alltid
    expire_in: 30 dager
    paths:
    - "*\/target\/reports"

.sonar_review:
  stage: bekrefte
  tags:
    - touchbit-shell
  dependencies: []
  script:
    - >
      if [ "$CI_BUILD_REF_NAME" == "master" ]; then
        mvn compile sonar:sonar -Dsonar.login=$SONAR_LOGIN $SONAR_ARGS
      else
        mvn compile sonar:sonar -Dsonar.login=$SONAR_LOGIN $SONAR_ARGS -Dsonar.analysis.mode=preview
      fi

.trigger_deploy:
  stage: distribuer
  tags:
    - touchbit-shell
  variables:
    URL: "https:\/\/gitlab.com\/api\/v4\/projects\/10345765\/trigger\/pipeline"
    POST_DATA: "
      token=${DEPLOY_TOKEN}&
      ref=master&
      variables[DEPLOY]=${DEPLOY}&
      variables[DEPLOY_CI_REPOSITORY_URL]=${CI_REPOSITORY_URL}&
      variables[DEPLOY_CI_PROJECT_NAME]=${CI_PROJECT_NAME}&
      variables[DEPLOY_CI_COMMIT_SHA]=${CI_COMMIT_SHA}&
      variables[DEPLOY_CI_COMMIT_TAG]=${CI_COMMIT_TAG}
      "
  script:
  - wget --content-on-error -qO- ${URL} --post-data ${POST_DATA}

.trigger_release_deploy:
  extends: .trigger_deploy
  only:
    - tags

.trigger_snapshot_deploy:
  extends: .trigger_deploy
  when: manual
  except:
    - tags

Som resultat ser .gitlab-ci.yml filene i java prosjekter ganske kompakte og ikke ordetette.

.gitlab-ci.yml

include: https:\/\/gitlab.com\/TouchBIT\/gitlab-ci\/raw\/master\/common.yml

Shields4J:
  extends: .build_java_project

Sphinx doc:
  extends: .build_sphinx_doc
  variables:
    DOCKERFILE: .docs\/Dockerfile

Sonar review:
  extends: .sonar_review
  dependencies:
    - Shields4J

Release:
  extends: .trigger_release_deploy

Snapshot:
  extends: .trigger_snapshot_deploy

Til innhold

Konfigurasjon av pom.xml

Dette emnet er beskrevet svært detaljert. Googolplex i Konfigurasjon av Maven for automatisk signering og opplasting av artefakter til snapshot- og staging-repositorier., derfor vil jeg beskrive noen nyanser ved bruk av plugin-moduler. Jeg vil også beskrive hvor lett og uanstrengt det er å bruke. nexus-staging-maven-plugin, hvis du ikke ønsker eller kan bruke org.sonatype.oss:oss-parent som forelder for prosjektet ditt.

maven-install-plugin

Installerer moduler i det lokale depotet.
Veldig nyttig for lokal verifisering av løsninger i andre prosjekter, samt for kontrollsum.

org.apache.maven.plugins
  maven-install-plugin
  
    
      install-project
      
      install
      
      
        target/${project.artifactId}-${project.version}.jar
        target/${project.artifactId}-${project.version}-sources.jar
        dependency-reduced-pom.xml
        
        true
        
        true

Til innhold

maven-javadoc-plugin

Generering av javadoc for prosjektet.

org.apache.maven.plugins
  maven-javadoc-plugin
  
    
      
        jar
      
      
      prepare-package
      
        
        true
        true
        
        false

Hvis du har et modul som ikke inneholder java (for eksempel bare ressurser)
Eller hvis du ikke ønsker å generere javadoc i det hele tatt, kan dette være til hjelp maven-jar-plugin

org.apache.maven.plugins
  maven-jar-plugin
  
    
      empty-javadoc-jar
      generate-resources
      
        jar
      
      
        javadoc
        ${basedir}/javadoc

Til innhold

maven-gpg-plugin

org.apache.maven.plugins
  maven-gpg-plugin
  
    
      sign-artifacts
      
      
      deploy
      
        sign

Til innhold

nexus-staging-maven-plugin

Konfigurasjon:

  
    
      
      
        org.sonatype.plugins
        nexus-staging-maven-plugin
      
    
    
      
        
          org.sonatype.plugins
          nexus-staging-maven-plugin
          true
          
            sonatype
            https://oss.sonatype.org/
            
            
            true
          
        
        
          org.apache.maven.plugins
          maven-deploy-plugin
          
            
            true
          
        
      
    
  
  
    
      sonatype
      Nexus Snapshot Repository
      https://oss.sonatype.org/content/repositories/snapshots/
    
    
      sonatype
      Nexus Release Repository
      https://oss.sonatype.org/service/local/staging/deploy/maven2/

Hvis du har et multi-modulprojekt og ikke har brug for at uploade et bestemt modul til repository'et, skal du tilføje nexus-staging-maven-plugin med flagget skipNexusStagingDeployMojo

org.sonatype.plugins
      nexus-staging-maven-plugin
      
        true

Efter upload af snapshot/release-versioner er de tilgængelige i staging-repositoriet

SonatypeNexus
    https://oss.sonatype.org/content/groups/staging/
    

Andre fordele

• En meget rig liste af mål for arbejde med nexus-repositoriet (mvn help:describe -Dplugin=org.sonatype.plugins:nexus-staging-maven-plugin).
• Automatisk kontrol af udgivelse for upload til maven central

Til innhold

Resultatet

Udgivelse af SNAPSHOT-version

Under byggeprocessen er der mulighed for manuelt at starte opgaven med at uploade SNAPSHOT-versionen til nexus

Når denne opgave køres, trigges den tilsvarende opgave i deploy-projektet (eksempel).

Afskåret log

Kjører med gitlab-runner 11.10.0 (3001a600)
  på Deploy runner JSKWyxUw
Bruker Shell-executor...
Kjører på ih1174328.vds.myihor.ru...
Hopper over oppsett av Git-repositoriet
Hopper over Git sjekk ut
Hopper over oppsett av Git underlag
$ rm -rf .* *
$ git config --global credential.helper store
$ echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" >> ~/ .git-credentials
$ git clone ${DEPLOY_CI_REPOSITORY_URL} .
Kloner inn i 'shields4j'...
$ git checkout ${DEPLOY_CI_COMMIT_SHA}
Merk: sjekker ut '850f86aa317194395c5387790da1350e437125a7'.
Du er i 'frakoblet HEAD'-tilstand. Du kan se deg rundt, gjøre eksperimentelle
endringer og lagre dem, og du kan forkaste ethvert commit du gjør i denne
tilstanden uten å påvirke noen grener ved å utføre en annen sjekk ut.
Hvis du vil opprette en ny gren for å beholde commits du lager, kan du
gjøre det (nå eller senere) ved å bruke -b med sjekk ut-kommandoen igjen. Eksempel:
  git checkout -b new_branch_name
HEAD er nå på 850f86a... hopp over distribusjonstest-kjernen
$ for pom in $(find . -name pom.xml); do # sammenrullet flerlinjekommando
$ if [[ "${DEPLOY_CI_COMMIT_TAG}" != "" ]]; then # sammenrullet flerlinjekommando
[INFO] Skanner etter prosjekter...
[INFO] Inspiserer bygg med totalt 4 moduler...
[INFO] Installerer Nexus Staging-funksjoner:
[INFO]   ... totalt 4 utførelser av maven-deploy-plugin erstattet med nexus-staging-maven-plugin
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Byggrekkefølge:
[INFO] 
[INFO] Shields4J                                                          [pom]
[INFO] test-kjerne                                                          [jar]
[INFO] Shields4J klient                                                   [jar]
[INFO] TestNG lytter                                                    [jar]
[INFO] 
[INFO] -----------------------------
[INFO] Bygger Shields4J 1.0.0                                           [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
[INFO] 
[INFO] --- versions-maven-plugin:2.5:set (default-cli) @ shields4j-parent ---
[INFO] Søker etter lokal aggregatorrot...
[INFO] Lokal aggregeringsrot: /home/gitlab-deployer/JSKWyxUw/0/TouchBIT/deploy/shields4j
[INFO] Behandler endring av org.touchbit.shields4j:shields4j-parent:1.0.0 -> 1.0.0-SNAPSHOT
[INFO] Behandler org.touchbit.shields4j:shields4j-parent
[INFO]     Oppdaterer prosjekt org.touchbit.shields4j:shields4j-parent
[INFO]         fra versjon 1.0.0 til 1.0.0-SNAPSHOT
[INFO] 
[INFO] Behandler org.touchbit.shields4j:klient
[INFO]     Oppdaterer foreldre org.touchbit.shields4j:shields4j-parent
[INFO]         fra versjon 1.0.0 til 1.0.0-SNAPSHOT
[INFO]     Oppdaterer avhengighet org.touchbit.shields4j:test-kjerne
[INFO]         fra versjon 1.0.0 til 1.0.0-SNAPSHOT
[INFO] 
[INFO] Behandler org.touchbit.shields4j:test-kjerne
[INFO]     Oppdaterer foreldre org.touchbit.shields4j:shields4j-parent
[INFO]         fra versjon 1.0.0 til 1.0.0-SNAPSHOT
[INFO] 
[INFO] Behandler org.touchbit.shields4j:testng
[INFO]     Oppdaterer foreldre org.touchbit.shields4j:shields4j-parent
[INFO]         fra versjon 1.0.0 til 1.0.0-SNAPSHOT
[INFO]     Oppdaterer avhengighet org.touchbit.shields4j:klient
[INFO]         fra versjon 1.0.0 til 1.0.0-SNAPSHOT
[INFO]     Oppdaterer avhengighet org.touchbit.shields4j:test-kjerne
[INFO]         fra versjon 1.0.0 til 1.0.0-SNAPSHOT
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Oppsummering:
[INFO] 
[INFO] Shields4J 1.0.0 .................................... SUKSESS [  0.992 s]
[INFO] test-kjerne .......................................... HOPPET OVER
[INFO] Shields4J klient ................................... HOPPET OVER
[INFO] TestNG lytter 1.0.0 .............................. HOPPET OVER
[INFO] ------------------------------------------------------------------------
[INFO] BYGG SUKSESS
[INFO] ------------------------------------------------------------------------
[INFO] Total tid: 2.483 s
[INFO] Ferdig kl. 2019-04-21T02:40:42+03:00
[INFO] ------------------------------------------------------------------------
$ mvn clean deploy -DskipTests=${SKIP_TESTS}
[INFO] Skanner etter prosjekter...
[INFO] Inspiserer bygg med totalt 4 moduler...
[INFO] Installerer Nexus Staging-funksjoner:
[INFO]   ... totalt 4 utførelser av maven-deploy-plugin erstattet med nexus-staging-maven-plugin
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Byggrekkefølge:
[INFO] 
[INFO] Shields4J                                                          [pom]
[INFO] test-kjerne                                                          [jar]
[INFO] Shields4J klient                                                   [jar]
[INFO] TestNG lytter                                                    [jar]
[INFO] 
[INFO] -----------------------------
[INFO] Bygger Shields4J 1.0.0-SNAPSHOT                                  [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
...
SLETTET
...
[INFO]  * Bulk distribusjon av lokalt samlet snapshot-artikler fullført.
[INFO] Fjerndistribusjon fullført med suksess.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Oppsummering:
[INFO] 
[INFO] Shields4J 1.0.0-SNAPSHOT ........................... SUKSESS [  2.375 s]
[INFO] test-kjerne .......................................... SUKSESS [  3.929 s]
[INFO] Shields4J klient ................................... SUKSESS [  3.815 s]
[INFO] TestNG lytter 1.0.0-SNAPSHOT ..................... SUKSESS [ 36.134 s]
[INFO] ------------------------------------------------------------------------
[INFO] BYGG SUKSESS
[INFO] ------------------------------------------------------------------------
[INFO] Total tid: 47.629 s
[INFO] Ferdig kl. 2019-04-21T02:41:32+03:00
[INFO] ------------------------------------------------------------------------

Som følge av dette er det lastet opp en versjon til nexus 1.0.0-SNAPSHOT.

Alle snapshot-versjoner kan slettes fra repositoret på nettstedet oss.sonatype.org under din konto.

Til innhold

Publisering av release-versjon

Når du installerer en tag, trigges automatisk oppgaven i prosjektet deploy for å laste opp den offisielle versjonen til nexus (eksempel).

Det mest behagelige er at close release i nexus automatisk utføres.

[INFO] Utfører ekstern staging...
[INFO] 
[INFO]  * Ekstern staging til staging-profil ID "9043b43f77dcc9"
[INFO]  * Opprettet staging-repositorium med ID "orgtouchbit-1037".
[INFO]  * Staging-repositorium på https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1037
[INFO]  * Laster opp lokalt staged artefakter til profil org.touchbit
[INFO]  * Opplasting av lokalt staged artefakter fullført.
[INFO]  * Lukking av staging-repositorium med ID "orgtouchbit-1037".
Venter på at operasjonen skal fullføres...
.........
[INFO] 1 eksternt staged repositors, fullført med suksess.
[INFO] ------------------------------------------------------------------------
[INFO] Oppsummering av reaktorer:
[INFO] 
[INFO] Shields4J 1.0.0 .................................... SUKSESS [  9.603 s]
[INFO] test-core .......................................... SUKSESS [  3.419 s]
[INFO] Shields4J-klient ................................... SUKSESS [  9.793 s]
[INFO] TestNG lytter 1.0.0 .............................. SUKSESS [01:23 min]
[INFO] ------------------------------------------------------------------------
[INFO] BYGG SUKSESS
[INFO] ------------------------------------------------------------------------
[INFO] Total tid: 01:47 min
[INFO] Fullført: 2019-04-21T04:05:46+03:00
[INFO] ------------------------------------------------------------------------

Og hvis noe gikk galt, vil oppgaven definitivt feile

[INFO] Utfører ekstern staging...
[INFO] 
[INFO]  * Ekstern staging inn i staging-profil ID "9043b43f77dcc9"
[INFO]  * Opprettet staging-repositorium med ID "orgtouchbit-1038".
[INFO]  * Staging-repositorium på https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1038
[INFO]  * Laster opp lokalt staging-artikler til profil org.touchbit
[INFO]  * Opplasting av lokalt staging-artikler fullført.
[INFO]  * Lukker staging-repositorium med ID "orgtouchbit-1038".
Venter på at operasjonen skal fullføres...
.......
[ERROR] Regelbrudd mens vi prøvde å lukke staging-repositorium med ID "orgtouchbit-1039".
[ERROR] 
[ERROR] Nexus Staging Rules Failure Report
[ERROR] ==================================
[ERROR] 
[ERROR] Repository "orgtouchbit-1039" feil
[ERROR]   Regel "signature-staging" feil
[ERROR]     * Ingen offentlig nøkkel: Nøkkel med id: (1f42b618d1cbe1b5) kunne ikke lokaliseres på http://keys.gnupg.net:11371/. Last opp din offentlige nøkkel og prøv operasjonen igjen.
...
[ERROR] Rydder opp i lokal staging-katalog etter en regelbrudd under lukking av staging-repositorier: [orgtouchbit-1039]
[ERROR]  * Sletter kontekst 9043b43f77dcc9.properties
[ERROR] Rydder opp i eksterne staging-repositorier etter en regelbrudd under lukking av staging-repositorier: [orgtouchbit-1039]
[ERROR]  * Fjerner mislykket staging-repositorium med ID "orgtouchbit-1039" (Regelbrudd under lukking av staging-repositorier: [orgtouchbit-1039]).
[ERROR] Ekstern staging avsluttet med en feil: Staging regler feil!
[INFO] ------------------------------------------------------------------------
[INFO] Reaktor Sammendrag:
[INFO] 
[INFO] Shields4J 1.0.0 .................................... SUKSESS [  4.073 s]
[INFO] test-core .......................................... SUKSESS [  2.788 s]
[INFO] Shields4J klient ................................... SUKSESS [  3.962 s]
[INFO] TestNG lytter 1.0.0 .............................. FEIL [01:07 min]
[INFO] ------------------------------------------------------------------------
[INFO] BYGGFEIL
[INFO] ------------------------------------------------------------------------

Som et resultat har vi bare ett valg igjen. Enten fjerne denne versjonen eller publisere den.

Etter utgivelsen, etter en stund, vil artefaktene være i

off-topic

Det var en åpenbaring for meg at maven indekserer andre offentlige repositorier.
Jeg måtte legge til robots.txt, da den indekserte mitt gamle repositorium.

Til innhold

Konklusjon

Hva har vi

• Et eget deploy-prosjekt der man kan implementere flere CI-oppgaver for opplasting av artefakter til offentlige repositorier for ulike utviklingsspråk.
• Deploy-prosjektet er isolert fra uautorisert innblanding og kan bare endres av brukere med rollen Eier og Vedlikeholder.
• En egen Specific Runner med 'varm' cache for å kun kjøre deploy-oppgaver.
• Publisering av snapshot/release versjoner i offentlig repositorium.
• Automatisk sjekk av release-versjonen for beredskap til publisering i maven central.
• Beskyttelse mot automatisk publisering av 'rå' versjoner i maven central.
• Bygging og publisering av snapshot versjoner 'med klikk'.
• Et felles repositorium for å motta snapshot/release versjoner.
• Fellesskapet for bygging/testing/publisering av java-prosjekter.

Oppsett av GitLab CI er ikke så vanskelig som det virker ved første øyekast. Det er nok å sette opp CI "nøkkelferdig" et par ganger, så er du allerede langt fra å være nybegynner i dette. Spesielt fordi GitLab-dokumentasjonen er ganske omfattende. Ikke vær redd for å ta det første steget. Veien former seg under føttene til den som går (husker ikke hvem som sa det 🙂 ).

Jeg ser frem til tilbakemeldinger.

I neste artikkel vil jeg fortelle om hvordan man setter opp GitLab CI for samtidig kjøring av oppgaver med integrasjonstester (med kjøring av testede tjenester ved hjelp av docker-compose), hvis du kun har én shell-runner.

Til innhold

Kilde: habr.com