ProHoster > Blog > Administrim > Konfigurimi i GitLab CI për ngarkimin e projektit java në maven central

Konfigurimi i GitLab CI për ngarkimin e projektit java në maven central

Kyç i këtij artikulli është për zhvilluesit java që kanë nevojë të publikojnë shpejt produktet e tyre në repositorët Sonatype dhe/ose Maven Central duke përdorur GitLab. Në këtë artikull, do të flas për konfigurimin e gitlab-runner, gitlab-ci dhe maven-plugin për të zgjidhur këtë detyrë.

Kushtet paraprake:

  • Ruajtja e sigurt e mvn dhe çelsojve GPG.
  • Ekzekutimi i sigurt i detyrave publike CI.
  • Ngarko artefaktet (release/snapshot) nĂ« repositorĂ« publik.
  • Kontrolli automatik i versioneve release pĂ«r publikim nĂ« Maven Central.
  • Zgjidhja e pĂ«rgjithshme pĂ«r ngarkimin e artefakteve nĂ« repository pĂ«r disa projekte.
  • ThjeshtĂ«sia dhe lehtĂ«sia e pĂ«rdorimit.

PĂ«rmbajtja

Informacion i përgjithshëm

  • PĂ«rshkrimi i detajuar i mekanizmit tĂ« publikimit tĂ« artefakteve nĂ« Maven Central pĂ«rmes ShĂ«rbimit tĂ« Hosting tĂ« RepositorĂ«ve OSS Sonatype Ă«shtĂ« pĂ«rshkruar tashmĂ« nĂ« kĂ«tĂ« artikull nga pĂ«rdoruesi Googolplex, ndaj nĂ« vendet e nevojshme do tĂ« bĂ«j referencĂ« nĂ« kĂ«tĂ« artikull.
  • PĂ«rpara, regjistrohemi nĂ« Sonatype JIRA dhe hapim njĂ« tiket pĂ«r hapjen e repositorit (lexoni mĂ« shumĂ« nĂ« seksionin Krijo tiket nĂ« Sonatype JIRA). Pas hapjes sĂ« repositorit, çifti login/fjalĂ«kalim nga JIRA (mĂ« pas llogaria Sonatype) do tĂ« pĂ«rdoret pĂ«r ngarkimin e artefakteve nĂ« Sonatype nexus.
  • MĂ« pas, procesi i generimit tĂ« çelsojve GPG pĂ«rshkruhet mjaft i thatĂ«. Shihni mĂ« shumĂ« nĂ« seksionin Konfigurimi i GnuPG pĂ«r nĂ«nshkrimin e artefakteve
  • NĂ«se pĂ«rdorni terminalin Linux pĂ«r tĂ« gjeneruar çelĂ«sin GPG (gnupg/gnupg2), Ă«shtĂ« e nevojshme tĂ« instaloni rng-tools pĂ«r gjenerimin e entropisĂ«. PĂ«rndryshe, gjenerimi i çelĂ«sit mund tĂ« marrĂ« shumĂ« kohĂ«.
  • ShĂ«rbimet e ruajtjes çelsojve GPG publikĂ«

Te përmbajtja

Konfigurimi i projektit deploy në GitLab

  • SĂ« pari, duhet tĂ« krijoni dhe konfiguroni njĂ« projekt ku do tĂ« ruhet pipeline, pĂ«r tĂ« deploy-uar artefaktet. Projketin tim e quajta thjesht dhe pa ndonjĂ« komplikuar - deploy
  • Pas krijimit tĂ« repositorit, Ă«shtĂ« e nevojshme tĂ« kufizoni aksesin pĂ«r tĂ« ndryshuar repositorin.
    Kaloni në projekt -> Settings -> Repository -> Protected Branches. Fshini të gjitha rregullat dhe shtoni një rregull të vetëm me Wildcard * me të drejta për push dhe merge vetëm për përdoruesit me rol Maintainers. Ky rregull do të funksionojë për të gjithë përdoruesit e këtij projekti, si dhe grupin në të cilin ky projekt përfshihet.
    Konfigurimi i GitLab CI për ngarkimin e projektit java në maven central
  • NĂ«se ka disa mbajtĂ«s, zgjidhja mĂ« e mirĂ« do tĂ« ishte tĂ« kufizoni aksesin nĂ« projekt nĂ« pĂ«rgjithĂ«si.
    Shkoni te projekti -> Settings -> General -> Visibility, project features, permissions dhe caktoni Project visibility në Privat.
    Unë kam projektin në akses publik, pasi përdor GitLab Runner tim dhe aksesin për të ndryshuar repository e kam vetëm për vete. Poashtu nuk është në interesin tim të ekspozoj informacion privat në logët publike të pipeline.
  • Rigorifikimi i rregullave pĂ«r ndryshimin e repository-t.
    Shkoni te projekti -> Settings -> Repository -> Push Rules dhe vendosni flag-un Committer restriction, Check whether author is a GitLab user. Po ashtu rekomandoj të konfiguroni nënshkrimin e kommitëve., dhe vendosni flag-un Reject unsigned commits.
  • MĂ« pas Ă«shtĂ« e nevojshme tĂ« konfigurohet njĂ« trigger pĂ«r tĂ« nisur detyrat.
    Shkoni te projekti -> Settings -> CI / CD -> Pipeline triggers dhe krijoni një trigger-token të ri.
    Ky token mund të shtohet menjëherë në konfigurimin e përgjithshëm të variablave për grupin e projekteve.
    Shkoni te grupi -> Settings -> CI / CD -> Variables dhe shtoni variablën DEPLOY_TOKEN me vlerën e trigger-token.

Te përmbajtja

GitLab Runner

Ky seksion përshkruan konfigurimin për nisjen e detyrave në deploy duke përdorur runner personal (Specific) dhe publik (Shared).

Runner specifik

Unë përdor runner të miat, pasi është e përshtatshme, e shpejtë dhe e lirë.
PĂ«r runner-in rekomandoj njĂ« VDS me 1 CPU, 2 GB RAM, 20 GB HDD. Çmimi Ă«shtĂ« rreth 3000â‚œ nĂ« vit.

Runner-i im

PĂ«r runner-in kam marrĂ« njĂ« VDS me 4 CPU, 4 GB RAM, 50 GB SSD. MĂ« ka kushtuar rreth 11000â‚œ dhe nuk kam penduar asnjĂ«herĂ«.
Në total kam 7 makineri. 5 në aruba dhe 2 në ihor.

Pra, tani kemi një runner. Tani do ta konfigurojmë atë.
Hyni në makinë përmes SSH dhe instaloni java, git, maven, gnupg2.

Te përmbajtja

Instaloni gitlab runner

  • Krijoni njĂ« grup tĂ« ri runner
    sudo groupadd runner
  • Krijoni njĂ« direktor pĂ«r cache-in e maven dhe caktoni tĂ« drejtat e grupit. runner
    Ky hap mund të lihet jashtë nëse nuk planifikoni të përdorni disa runner në të njëjtën makinë.
    mkdir -p /usr/cache/.m2/repository
chown -R :runner /usr/cache
chmod -R 770 /usr/cache
  • KrijojmĂ« pĂ«rdorues gitlab-deployer dhe shtoni nĂ« grup. runner
    useradd -m -d /home/gitlab-deployer gitlab-deployer
usermod -a -G runner gitlab-deployer
  • Shtoni nĂ« skedarin /etc/ssh/sshd_config rreshtin e mĂ«poshtĂ«m.
    AllowUsers root@* gitlab-deployer@127.0.0.1
  • Rinovoni sshd
    systemctl restart sshd
  • Krijoni njĂ« fjalĂ«kalim pĂ«r pĂ«rdoruesin. gitlab-deployer (mund tĂ« jetĂ« e thjeshtĂ«, pasi ka njĂ« kufizim pĂ«r localhost).
    passwd gitlab-deployer
  • Instaloni 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
  • Shkoni nĂ« faqen gitlab.com -> deploy-project -> Settings -> CI/CD -> Runners -> Specific Runners dhe kopjoni tokenin e regjistrimit

Screenshot

Konfigurimi i GitLab CI për ngarkimin e projektit java në maven central

  • Regjistroni runner-in
    gitlab-runner register --config /etc/gitlab-runner/gitlab-deployer-config.toml

Në ditën e fillimit të modulit, struktura e tij bëhet e disponueshme. Studimi në UoL përbëhet nga cikli në vijim:

Platforma e runtime-së arch=amd64 os=linux pid=17594 revision=3001a600 version=11.10.0
Duke funksionuar në modalitetin sistemor.
Ju lutemi, shkruani URL-në e koordinatori gitlab-ci (p.sh. https://gitlab.com/):
https://gitlab.com/
Ju lutemi, shkruani tokenin gitlab-ci për këtë runner:
REGISTRATION_TOKEN
Ju lutemi, shkruani përshkrimin gitlab-ci për këtë runner:
[ih1174328.vds.myihor.ru]: Deploy Runner
Ju lutemi, shkruani etiketat gitlab-ci për këtë runner (të ndara me presje):
deploy
Duke regjistruar runner-in... u suksesshëm                     runner=ZvKdjJhx
Ju lutemi, shkruani_executor-in: docker-ssh, parallels, virtualbox, docker-ssh+machine, kubernetes, docker, ssh, docker+machine, shell:
shell
Runner i regjistruar me sukses. Mos hezitoni ta filloni, por nëse është duke funksionuar tashmë, konfigurimi duhet të rifreskohet automatikisht!
  • Kontrolloni nĂ«se runner-i Ă«shtĂ« regjistruar. Shkoni nĂ« faqen gitlab.com -> deploy-project -> Settings -> CI/CD -> Runners -> Specific Runners -> Runners aktivĂ« pĂ«r kĂ«tĂ« projekt

Screenshot

Konfigurimi i GitLab CI për ngarkimin e projektit java në maven central

  • Shtoni tĂ« veçantĂ« shĂ«rbimin /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
  • Filloni shĂ«rbimin.
    systemctl enable gitlab-deployer.service
systemctl start gitlab-deployer.service
systemctl status gitlab-deployer.service
  • Kontrolloni nĂ«se runner-i Ă«shtĂ« aktiv.

Shembulli

Konfigurimi i GitLab CI për ngarkimin e projektit java në maven central

Te përmbajtja

Generimi i çelsojve GPG

  • Nga kjo makinĂ« hyni pĂ«rmes ssh si pĂ«rdoruesi gitlab-deployer (kjo Ă«shtĂ« e rĂ«ndĂ«sishme pĂ«r gjenerimin e çelĂ«sit GPG)
    ssh gitlab-deployer@127.0.0.1
  • Gjeneroni çelĂ«sin duke iu pĂ«rgjigjur pyetjeve. UnĂ« pĂ«rdora emrin dhe emailin tim tĂ« pronarit.
    Sigurohuni të tregoni fjalëkalim për çelësin. Ky çelës do të përdoret për të nënshkruar artefaktet.
    gpg --gen-key
  • Po kontrollojmĂ«
    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
  • Ngarko çelĂ«sin tuaj publik nĂ« serverin e çelĂ«save
    gpg --keyserver keys.gnupg.net --send-key 00000000
gpg: duke dërguar çelësin 00000000 në serverin hkp keys.gnupg.net

Te përmbajtja

Konfigurimi i Maven

  • Hyni si pĂ«rdoruesi gitlab-deployer
    su gitlab-deployer
  • Krijoni direktorinĂ« maven repository dhe lidhni me cache (mos gaboni)
    Ky pikë mund të lihet përjashtim, nëse nuk planifikoni të nisni disa runners në të njëjtën makinë.
    mkdir -p ~/.m2/repository
ln -s /usr/cache/.m2/repository /home/gitlab-deployer/.m2/repository
  • Krijoni çelĂ«sin kryesor
    mvn --encrypt-master-password password
{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}
  • Krijoni skedarin ~/.m2/settings-security.xml
    {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}
  • KrijojmĂ« njĂ« fjalĂ«kalim pĂ«r llogarinĂ« Sonatype
    mvn --encrypt-password SONATYPE_PASSWORD
{98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}
  • KrijojmĂ« skedarin ~/ .m2/ settings.xml
    env
        
            true
        
        
            GPG_SECRET_KEY_PASSPHRASE
        
    


    
        sonatype
        SONATYPE_USERNAME
        {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}

ku,
GPG_SECRET_KEY_PASSPHRASE — fjalĂ«kalimi pĂ«r çelĂ«sin GPG
SONATYPE_USERNAME — emri i pĂ«rdoruesit pĂ«r llogarinĂ« sonatype

Këtu përfundon konfigurimi i runner-it, mund të kaloni në seksionin GitLab CI

Te përmbajtja

Runner të shpërndarë

Generimi i çelsojve GPG

  • SĂ« pari, Ă«shtĂ« e nevojshme tĂ« krijoni njĂ« çelĂ«s GPG. PĂ«r kĂ«tĂ« instalohet gnupg.
    yum install -y gnupg
  • Gjenieroni çelĂ«sin duke iu pĂ«rgjigjur pyetjeve. UnĂ« pĂ«rdora emrin dhe emailin tim personal. Sigurohuni tĂ« tregoni fjalĂ«kalimin pĂ«r çelĂ«sin.
    gpg --gen-key
  • Shfaqim informacionin rreth çelĂ«sit
    gpg --list-keys -a
pub   rsa3072 2019-04-24 [SC] [skadon: 2021-04-23]
  2D0D1706366FC4AEF79669E24D09C55BBA3FD728
uid           [fundamental] tttemp 
sub   rsa3072 2019-04-24 [E] [skadon: asnjë]
  • Ngarko çelĂ«sin tuaj publik nĂ« serverin e çelĂ«save
    gpg --keyserver keys.gnupg.net --send-key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728
gpg: dërgimi i çelësit 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 te serveri hkp keys.gnupg.net
  • Marrim çelĂ«sin privat
    gpg --export-secret-keys --armor 2D0D1706366FC4AEF79669E24D09C55BBA3FD728
-----BEGIN PGP PRIVATE KEY BLOCK-----
lQWGBFzAqp8BDADN41CPwJ/gQwiKEbyA902DKw/WSB1AvZQvV/ZFV77xGeG4K7k5
...
=2Wd2
-----END PGP PRIVATE KEY BLOCK-----
  • KalojmĂ« nĂ« konfigurimin e projektit -> Settings -> CI / CD -> Variables dhe ruajmĂ« çelĂ«sin privat nĂ« variablin GPG_SECRET_KEY
    Konfigurimi i GitLab CI për ngarkimin e projektit java në maven central

Te përmbajtja

Konfigurimi i Maven

  • Krijoni çelĂ«sin kryesor
    mvn --encrypt-master-password password
{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}
  • KalojmĂ« nĂ« konfigurimin e projektit -> Settings -> CI / CD -> Variables dhe ruajmĂ« nĂ« variablin SETTINGS_SECURITY_XML lini kĂ«to rreshta:
    {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}
  • KrijojmĂ« njĂ« fjalĂ«kalim pĂ«r llogarinĂ« Sonatype
    mvn --encrypt-password SONATYPE_PASSWORD
{98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}
  • KalojmĂ« nĂ« konfigurimin e projektit -> Settings -> CI / CD -> Variables dhe ruajmĂ« nĂ« variablin SETTINGS_XML lini kĂ«to rreshta:
    env
        
            true
        
        
            GPG_SECRET_KEY_PASSPHRASE
        
    


    
        sonatype
        sonatype_username
        {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}

ku,
GPG_SECRET_KEY_PASSPHRASE — fjalĂ«kalimi pĂ«r çelĂ«sin GPG
SONATYPE_USERNAME — emri i pĂ«rdoruesit pĂ«r llogarinĂ« sonatype

Te përmbajtja

Deploy imazhin docker

  • KrijojmĂ« njĂ« Dockerfile tĂ« thjeshtĂ« pĂ«r tĂ« ekzekutuar detyrat nĂ« deploy me versionin e nevojshĂ«m tĂ« Java. MĂ« poshtĂ« jepet njĂ« shembull pĂ«r alpine.
    FROM 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/
  • KrijojmĂ« konteinerin pĂ«r projektin tuaj
    docker build -t registry.gitlab.com/group/deploy .
  • Autentikohuni dhe ngarkoni konteinerin nĂ« registry.
    docker login -u USER -p PASSWORD registry.gitlab.com
docker push registry.gitlab.com/group/deploy

Te përmbajtja

GitLab CI

Deploy projektin

Shtojmë në rrënjën e projektit deploy skedarin .gitlab-ci.yml
Në skenarin paraqiten dy detyra për deploy që përjashtojnë njëra-tjetrën. Specific Runner ose Shared Runner përkatësisht.

.gitlab-ci.yml

stages:
  - deploy

Specific Runner:
  extends: .java_deploy_template
  # Detyra do të ekzekutohet në shell-runners tuaj
  tags:
    - deploy

Shared Runner:
  extends: .java_deploy_template
  # Detyra do të ekzekutohet në docker-runner publik
  tags:
    - docker
  # Imazh nga seksioni GitLab Runner -> Shared Runner -> Docker
  image: registry.gitlab.com/group/deploy-project:latest
  before_script:
    # Importojmë çelësin GPG
    - printf "${GPG_SECRET_KEY}" | gpg --batch --import
    # Ruajmë konfigurimin maven
    - printf "${SETTINGS_SECURITY_XML}" > ~/ .m2/settings-security.xml
    - printf "${SETTINGS_XML}" > ~/ .m2/settings.xml

.java_deploy_template:
  stage: deploy
  # Detyra do të aktivizohet me trigger-in, nëse jepet variabla DEPLOY me vlerën java
  only:
    variables:
    - $DEPLOY == "java"
  variables:
    # ndalojmë klonimin e projektit aktual
    GIT_STRATEGY: none
  script:
    # Ofroni mundësinë e ruajtjes së fjalëkalimit në formë të pa-enkriptuar
    - git config --global credential.helper store
    # Ruajmë kredencialet për përdoruesin gitlab-ci-token
    # Token funksionon për të gjitha projektet publike gitlab.com dhe për projektet e grupit
    - echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" >> ~/ .git-credentials
    # Pjesa më e madhe e drejtorisë aktuale
    - rm -rf .* *
    # Klonojmë projektin që do të vendosim në Sonatype Nexus
    - git clone ${DEPLOY_CI_REPOSITORY_URL} .
    # Kthehemi në komitin e duhur
    - git checkout ${DEPLOY_CI_COMMIT_SHA} -f
    # Nëse ndonjë pom.xml përmban parametrin autoReleaseAfterClose, prishim ndërtimin.
    # Ndryshe, ka rrezik të ngarkohet arti i papërfunduar në maven central
    - >
      for pom in $(find . -name pom.xml); do
        if [[ $(grep -q autoReleaseAfterClose "$pom" && echo $?) == 0 ]]; then
          echo "File $pom përmban cilësimin e ndaluar: ";
          exit 1;
        fi;
      done
    # Nëse parametri DEPLOY_CI_COMMIT_TAG është i zbrazët, atëherë vendosim forcërisht versionin SNAPSHOT
    - >
      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
    # Ekzekutojmë detyrën për ndërtimin dhe vendosjen e artefakteve
    - mvn clean deploy -DskipTests=true

Te përmbajtja

Projekti Java

Në projektet java që pritet të ngarkohen në repozitorë publikë, është e nevojshme të shtojmë 2 hapa për ngarkimin e versioneve Release dhe Snapshot.

.gitlab-ci.yml

etapat:
  - ndërtim
  - test
  - verifikim
  - shpërndarje

Release:
  extends: .trigger_deploy
  # Ekzekuto këtë detyrë vetëm për etiketat.
  only:
    - tags

Snapshot:
  extends: .trigger_deploy
  # Ekzekutojmë detyrën për publikimin e versionit SNAPSHOT manualisht
  when: manual
  # Mos e ekzekuto këtë detyrë nëse është vendosur një etiketë.
  except:
    - tags

.trigger_deploy:
  stage: deploy
  variables:
    # ÇaktivizojmĂ« klonimin e projektit aktual
    GIT_STRATEGY: none
    # Linku për detyrën e triggerit të deploy-it
    URL: "https://gitlab.com/api/v4/projects//trigger/pipeline"
    # Variablat për detyrën e deploy-it
    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:
    # Nuk përdor cURL, sepse me flagat --fail --show-error
    # nuk e printon trupin e përgjigjes, nëse kodi HTTP është 400 dhe më shumë 
    - wget --content-on-error -qO- ${URL} --post-data ${POST_DATA}

Në këtë zgjidhje shkuam pak më tej dhe vendosa të përdor një model CI për projektet java.

Më hollësisht

Krijova një projekt të veçantë gitlab-ci ku vendosa modelin CI për projektet java common.yml.

common.yml

etapat:
  - ndërtim
  - test
  - verifikim
  - shpërndarje

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

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

.build_sphinx_doc:
  stage: build
  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: test
  tags:
    - touchbit-shell
  variables:
    MODULE: ""
  script:
    - cd ${MODULE}
    - mvn test
  artifacts:
    when: always
    expire_in: 30 ditë
    paths:
      - "*\/target\/reports"

.junit_test_run:
  stage: test
  tags:
    - touchbit-shell
  script:
    - mvn test
  artifacts:
    when: always
    expire_in: 30 ditë
    paths:
    - "*\/target\/reports"

.sonar_review:
  stage: verify
  tags:
    - touchbit-shell
  dependencies: []
  script:
    - >
      nëse [ "$CI_BUILD_REF_NAME" == "master" ]; atëherë
        mvn compile sonar:sonar -Dsonar.login=$SONAR_LOGIN $SONAR_ARGS
      përndryshe
        mvn compile sonar:sonar -Dsonar.login=$SONAR_LOGIN $SONAR_ARGS -Dsonar.analysis.mode=preview
      fi

.trigger_deploy:
  stage: deploy
  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

Si e verifikon se në vetë projektet java, .gitlab-ci.yml duket mjaft kompakt dhe jo fjalë më fjalë.

.gitlab-ci.yml

përfshi: https://gitlab.com/TouchBIT/gitlab-ci/raw/master/common.yml

Shields4J:
  zgjeron: .build_java_project

Sphinx doc:
  zgjeron: .build_sphinx_doc
  variablat:
    DOCKERFILE: .docs/Dockerfile

Sonar review:
  zgjeron: .sonar_review
  varësitë:
    - Shields4J

Releasë:
  zgjeron: .trigger_release_deploy

Snapshot:
  zgjeron: .trigger_snapshot_deploy

Te përmbajtja

Konfigurimi i pom.xml

Ky temë është përshkruar shumë në detaje. Googolplex në Konfigurimi i Maven për nënshkrimin automatik dhe ngarkimin e artefakteve në depozitë snapshot dhe staging., prandaj do të përshkruaj disa nuanca të përdorimit të plaginave. Gjithashtu do të përshkruaj se si lehtë dhe pa ndonjë ngarkesë mund të përdorni nexus-staging-maven-plugin, nëse nuk dëshironi ose nuk mund të përdorni org.sonatype.oss:oss-parent si prind për projektin tuaj.

maven-install-plugin

Installon modulat në depozitin lokal.
Mjaft e dobishme për verifikimin lokal të zgjidhjeve në projekte të tjera, si dhe për kontrollin e sumave.

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

Te përmbajtja

maven-javadoc-plugin

Generimi i javadoc për projektin.

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

Nëse keni një modul që nuk përmban java (p.sh. vetëm burime)
Ose nëse nuk dëshironi që në përgjithësi të gjeneroni javadoc, atëherë në ndihmë maven-jar-plugin

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

Te përmbajtja

maven-gpg-plugin

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

Te përmbajtja

nexus-staging-maven-plugin

Konfigurimi:


  
    
      
      
        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/

Nëse keni një projekt me shumë module dhe nuk keni nevojë të ngarkoni një modul të caktuar në depo, atëherë në pom.xml të këtij moduli duhet të shtoni nexus-staging-maven-plugin me flamurin skipNexusStagingDeployMojo

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

Pas ngarkimit, versionet snapshot/release janë të disponueshme në repo staging

SonatypeNexus
    https://oss.sonatype.org/content/groups/staging/
    <!--

Më shumë përfitime

  • NjĂ« listĂ« shumĂ« tĂ« pasur qĂ«llimesh pĂ«r tĂ« punuar me depot nexus (mvn help:describe -Dplugin=org.sonatype.plugins:nexus-staging-maven-plugin).
  • Kontroll automatik i lĂ«shimit pĂ«r mundĂ«sinĂ« e ngarkesĂ«s nĂ« maven central

Te përmbajtja

Rezultati

Publikimi i versionit SNAPSHOT

Gjatë ndërtimit të projektit, ka mundësi për të nisur në mënyrë manuale detyrën për ngarkimin e versionit SNAPSHOT në nexus

Konfigurimi i GitLab CI për ngarkimin e projektit java në maven central

Kur niset kjo detyrë, aktivizohet detyra përkatës në projektin deploy (është).

Logs i prerë

Ekzekutimi me gitlab-runner 11.10.0 (3001a600)
  në Deploy runner JSKWyxUw
Duke përdorur ekzekutorin Shell...
Duke punuar në ih1174328.vds.myihor.ru...
Të dhënat e Git-it janë duke u anashkaluar
Të dhënat e kontrollit të Git-it janë duke u anashkaluar
Të dhënat e submoduleve të Git-it janë duke u anashkaluar
$ 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} .
Klonimi në 'shields4j'...
$ git checkout ${DEPLOY_CI_COMMIT_SHA}
Shënim: duke kontrolluar '850f86aa317194395c5387790da1350e437125a7'.
Jeni në gjendjen 'detached HEAD'. Mund të bëni ndryshime eksperimentale
dhe t'i angazhoni ato, dhe mund të anashkaloni çdo angazhim që bëni në këtë
shtet pa ndikuar në ndonjë degë duke bërë një kontroll të ri.
Nëse dëshironi të krijoni një degë të re për të mbajtur angazhimet që krijoni, mund
të bëni këtë (tani ose më vonë) duke përdorur -b me komandën e kontrollit përsëri. Shembull:
  git checkout -b new_branch_name
HEAD tani është në 850f86a... anashkaloni testin e shpërndarjes
$ për pom në $(find . -name pom.xml); bëj # komandë e shumëfishtë e anashkaluar
$ nëse [[ "${DEPLOY_CI_COMMIT_TAG}" != "" ]]; atëherë # komandë e shumëfishtë e anashkaluar
[INFO] Scanuar për projekte...
[INFO] Duke kontrolluar ndërtimin me një total prej 4 moduleve...
[INFO] Duke instaluar karakteristikat e Nexus Staging:
[INFO]   ... një total prej 4 ekzekutimesh të maven-deploy-plugin të zëvendësuar me nexus-staging-maven-plugin
[INFO] ------------------------------------------------------------------------
[INFO] Renditja e Ndërtimit të Reaktorit:
[INFO] 
[INFO] Shields4J                                                          [pom]
[INFO] test-core                                                          [jar]
[INFO] Klienti Shields4J                                                   [jar]
[INFO] DĂ«gjuesi TestNG                                                    [jar]
[INFO] 
[INFO] -----------------------------
[INFO] Duke ndërtuar Shields4J 1.0.0                                           [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
[INFO] 
[INFO] --- versions-maven-plugin:2.5:set (default-cli) @ shields4j-parent ---
[INFO] Duke kërkuar rrënjën e agregatorit lokal...
[INFO] Rrënja lokale e agregatës: /home/gitlab-deployer/JSKWyxUw/0/TouchBIT/deploy/shields4j
[INFO] Duke përpunuar ndryshimin e org.touchbit.shields4j:shields4j-parent:1.0.0 -> 1.0.0-SNAPSHOT
[INFO] Duke përpunuar org.touchbit.shields4j:shields4j-parent
[INFO]     Duke përditësuar projektin org.touchbit.shields4j:shields4j-parent
[INFO]         nga versioni 1.0.0 në 1.0.0-SNAPSHOT
[INFO] 
[INFO] Duke përpunuar org.touchbit.shields4j:client
[INFO]     Duke përditësuar prindin org.touchbit.shields4j:shields4j-parent
[INFO]         nga versioni 1.0.0 në 1.0.0-SNAPSHOT
[INFO]     Duke përditësuar varësinë org.touchbit.shields4j:test-core
[INFO]         nga versioni 1.0.0 në 1.0.0-SNAPSHOT
[INFO] 
[INFO] Duke përpunuar org.touchbit.shields4j:test-core
[INFO]     Duke përditësuar prindin org.touchbit.shields4j:shields4j-parent
[INFO]         nga versioni 1.0.0 në 1.0.0-SNAPSHOT
[INFO] 
[INFO] Duke përpunuar org.touchbit.shields4j:testng
[INFO]     Duke përditësuar prindin org.touchbit.shields4j:shields4j-parent
[INFO]         nga versioni 1.0.0 në 1.0.0-SNAPSHOT
[INFO]     Duke përditësuar varësinë org.touchbit.shields4j:client
[INFO]         nga versioni 1.0.0 në 1.0.0-SNAPSHOT
[INFO]     Duke përditësuar varësinë org.touchbit.shields4j:test-core
[INFO]         nga versioni 1.0.0 në 1.0.0-SNAPSHOT
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] PĂ«rmbledhja e Reaktorit:
[INFO] 
[INFO] Shields4J 1.0.0 .................................... SUKSES [  0.992 s]
[INFO] test-core .......................................... SKIPUAR
[INFO] Klienti Shields4J ................................... SKIPUAR
[INFO] DĂ«gjuesi TestNG 1.0.0 .............................. SKIPUAR
[INFO] ------------------------------------------------------------------------
[INFO] NDËRTIM SUKSES
[INFO] ------------------------------------------------------------------------
[INFO] Koha totale: 2.483 s
[INFO] Përfunduar në: 2019-04-21T02:40:42+03:00
[INFO] ------------------------------------------------------------------------
$ mvn clean deploy -DskipTests=${SKIP_TESTS}
[INFO] Scanuar për projekte...
[INFO] Duke kontrolluar ndërtimin me një total prej 4 moduleve...
[INFO] Duke instaluar karakteristikat e Nexus Staging:
[INFO]   ... një total prej 4 ekzekutimesh të maven-deploy-plugin të zëvendësuar me nexus-staging-maven-plugin
[INFO] ------------------------------------------------------------------------
[INFO] Renditja e Ndërtimit të Reaktorit:
[INFO] 
[INFO] Shields4J                                                          [pom]
[INFO] test-core                                                          [jar]
[INFO] Klienti Shields4J                                                   [jar]
[INFO] DĂ«gjuesi TestNG                                                    [jar]
[INFO] 
[INFO] -----------------------------
[INFO] Duke ndërtuar Shields4J 1.0.0-SNAPSHOT                                  [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
...
TË FSHIHA
...
[INFO]  * Shpërndarja masive e artefakteve të grumbulluar vendore të snapshot është përfunduar.
[INFO] Shpërndarja e largët përfundoi me sukses.
[INFO] ------------------------------------------------------------------------
[INFO] PĂ«rmbledhja e Reaktorit:
[INFO] 
[INFO] Shields4J 1.0.0-SNAPSHOT ........................... SUKSES [  2.375 s]
[INFO] test-core .......................................... SUKSES [  3.929 s]
[INFO] Klienti Shields4J ................................... SUKSES [  3.815 s]
[INFO] DĂ«gjuesi TestNG 1.0.0-SNAPSHOT ..................... SUKSES [ 36.134 s]
[INFO] ------------------------------------------------------------------------
[INFO] NDËRTIM SUKSES
[INFO] ------------------------------------------------------------------------
[INFO] Koha totale: 47.629 s
[INFO] Përfunduar në: 2019-04-21T02:41:32+03:00
[INFO] ------------------------------------------------------------------------

Si pasojë, një version është ngarkuar në nexus 1.0.0-SNAPSHOT.

Të gjitha versionet snapshot mund të fshihen nga repository në sitin oss.sonatype.org në llogarinë tuaj.

Konfigurimi i GitLab CI për ngarkimin e projektit java në maven central

Te përmbajtja

Publikimi i versionit release

Kur vendosni etiketën, një detyrë përkatëse në projektin deploy për ngarkimin e versionit të publikimit në nexus aktivizohet automatikisht (është).

Konfigurimi i GitLab CI për ngarkimin e projektit java në maven central

Më e mira është se mbyllja e publikimit në nexus aktivizohet automatikisht.

[INFO] Duke realizuar skenimin e largët...
[INFO] 
[INFO]  * Skenimi i largët në profilin e skenimit ID "9043b43f77dcc9"
[INFO]  * Repo e skenimit të krijuar me ID "orgtouchbit-1037".
[INFO]  * Repo e skenimit në https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1037
[INFO]  * Dërgimi i artikujve të skenuar lokal për profilin org.touchbit
[INFO]  * Dërgimi i artikujve të skanuar lokal përfundoi.
[INFO]  * Duke mbyllur repo e skenimit me ID "orgtouchbit-1037".
Këtu po presim për përfundimin e operacionit...
.........
[INFO] Skenimi i largët për 1 repo, përfundoi me sukses.
[INFO] ------------------------------------------------------------------------
[INFO] I përmbledhuri i reaktorit:
[INFO] 
[INFO] Shields4J 1.0.0 .................................... SUKSES [  9.603 s]
[INFO] test-core .......................................... SUKSES [  3.419 s]
[INFO] Klienti Shields4J ................................... SUKSES [  9.793 s]
[INFO] DĂ«gjuesi TestNG 1.0.0 .............................. SUKSES [01:23 min]
[INFO] ------------------------------------------------------------------------
[INFO] NDËRTIM SUKSES
[INFO] ------------------------------------------------------------------------
[INFO] Koha totale: 01:47 min
[INFO] Përfunduar në: 2019-04-21T04:05:46+03:00
[INFO] ------------------------------------------------------------------------

Dhe nëse diçka shkoi keq, detyra do të dështojë patjetër

[INFO] Po kryerjen e skenimit të largët...
[INFO] 
[INFO]  * Skenim i largët në profilin e skenimit ID "9043b43f77dcc9"
[INFO]  * Kreu repository-n e skenimit me ID "orgtouchbit-1038".
[INFO]  * Repository i skenimit në https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1038
[INFO]  * Ngarkimi i artefakteve të skenuara lokalisht në profilin org.touchbit
[INFO]  * Ngarkimi i artefakteve të skenuara lokalisht përfundoi.
[INFO]  * Duke mbyllur repository-n e skenimit me ID "orgtouchbit-1038".
Duke pritur për të përfunduar operacionin...
.......
[ERROR] Dështimi i rregullave gjatë përpjekjes për të mbyllur repository-n e skenimit me ID "orgtouchbit-1039".
[ERROR] 
[ERROR] Raporti i dështimeve të rregullave të Nexus Staging
[ERROR] ==================================
[ERROR] 
[ERROR] DĂ«shtimet e repository-it "orgtouchbit-1039"
[ERROR]   Dështimet e rregullës "signature-staging"
[ERROR]     * Nuk ka çelĂ«s publik: ÇelĂ«si me id: (1f42b618d1cbe1b5) nuk u gjet nĂ« &lt;a href=http://keys.gnupg.net:11371/&gt;http://keys.gnupg.net:11371/&lt;/a&gt;. Ngarko çelĂ«sin tuaj publik dhe provoni pĂ«rsĂ«ri operacionin.
...
[ERROR] Pastrimi i direktorisë lokale të skenimit pasi një dështim rregullash gjatë mbylljes së repository-ve të skenimit: [orgtouchbit-1039]
[ERROR]  * Duke fshirë kontekstin 9043b43f77dcc9.properties
[ERROR] Pastrimi i repository-ve të skenuara larg nga një dështim rregullash gjatë mbylljes së repository-ve të skenimit: [orgtouchbit-1039]
[ERROR]  * Duke hequr repository-n e skenimit të dështuar me ID "orgtouchbit-1039" (Dështim rregullash gjatë mbylljes së repository-ve të skenimit: [orgtouchbit-1039]).
[ERROR] Skenimi i largët përfundoi me një dështim: Dështimi i rregullave të skenimit!
[INFO] ------------------------------------------------------------------------
[INFO] Përmbledhja e reaktorëve:
[INFO] 
[INFO] Shields4J 1.0.0 .................................... SUKSES [  4.073 s]
[INFO] test-core .......................................... SUKSES [  2.788 s]
[INFO] Klienti Shields4J ................................... SUKSES [  3.962 s]
[INFO] DĂ«gjuesi TestNG 1.0.0 .............................. DËSHTIM [01:07 min]
[INFO] ------------------------------------------------------------------------
[INFO] DËSHTIM I NDËRTIMEVE
[INFO] ------------------------------------------------------------------------

Si rezultat, na mbetet vetëm një zgjedhje. Ose të fshijmë këtë version ose ta publikojmë.

Konfigurimi i GitLab CI për ngarkimin e projektit java në maven central

Pas publikimit, pas disa kohësh artefaktet do të shpërndahen në Konfigurimi i GitLab CI për ngarkimin e projektit java në maven central

off-topic

Më bëri përshtypje që maven indeksonte repository të tjera publike.
Duhej të shtoja robots.txt, sepse ai indeksoi repository-n tim të vjetër.

Te përmbajtja

PĂ«rfundim

ÇfarĂ« kemi

  • NjĂ« projekt tĂ« veçantĂ« tĂ« deploy-n ku mund tĂ« realizohen disa punĂ« CI pĂ«r ngarkimin e artefakteve nĂ« repository tĂ« publikuara pĂ«r gjuhĂ« tĂ« ndryshme zhvillimi.
  • Projekti i deploy-it Ă«shtĂ« i izoluar nga ndĂ«rhyrjet e jashtme dhe mund tĂ« ndryshohet vetĂ«m nga pĂ«rdoruesit me rol Pronari dhe Mantues.
  • NjĂ« Runner tĂ« veçantĂ« me njĂ« cache "nĂ« funksion" pĂ«r tĂ« ekzekutuar vetĂ«m detyrat e deploy-it.
  • Publikimi i versioneve snapshot/release nĂ« njĂ« repository tĂ« publikuar.
  • Kontrollim automatik tĂ« versionit release pĂ«r gatishmĂ«rinĂ« pĂ«r publikim nĂ« maven central.
  • Mbrojtje nga publikimi automatik i versioneve "tĂ« papjekura" nĂ« maven central.
  • NdĂ«rtimi dhe publikimi i versioneve snapshot "me njĂ« klik".
  • NjĂ« repository i vetĂ«m pĂ«r marrjen e versioneve snapshot/release.
  • Pipeline i pĂ«rgjithshĂ«m pĂ«r ndĂ«rtimin/testimin/publikimin e projektit java.

Konfigurimi i GitLab CI nuk Ă«shtĂ« njĂ« temĂ« aq e komplikuar siç duket nĂ« shikim tĂ« parĂ«. Mjafton ta konfiguroni disa herĂ« CI "nga fillimi" dhe, ja, tashmĂ« nuk jeni njĂ« fillestar nĂ« kĂ«tĂ« fushĂ«. PĂ«r mĂ« tepĂ«r, dokumentacioni i GitLab Ă«shtĂ« mjaft i bollshmĂ«. Mos e frikĂ«soni hapat e parĂ«. RrugĂ«t shfaqen nĂ«n hapat e atyre qĂ« ecin (nuk e mbaj mend kush tha 🙂 ).

Do të isha i lumtur për feedback.

Në artikullin e ardhshëm do të flas për si të konfiguroni GitLab CI për ekzekutimin paralel të detyrave me teste integrimi (me ekzekutimin e shërbimeve që po testohen përmes docker-compose), nëse keni vetëm një shell runner.

Te përmbajtja

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster