GitLab CI-ის დაყენება java პროექტის ასატვირთად maven central-ში

ეს სტატია განკუთვნილია Java დეველოპერებისთვის, რომლებსაც აქვთ საჭიროება სწრაფად გამოაქვეყნონ თავიანთი პროდუქტები sonatype და/ან maven ცენტრალურ საცავებში GitLab-ის გამოყენებით. ამ სტატიაში ვისაუბრებ gitlab-runner, gitlab-ci და maven-plugin-ის დაყენებაზე ამ პრობლემის გადასაჭრელად.

წინაპირობები:

• mvn და GPG გასაღებების უსაფრთხო შენახვა.
• საჯარო CI ამოცანების უსაფრთხო შესრულება.
• არტეფაქტების ატვირთვა (გამოცემა/სნეპშოტი) საჯარო საცავებში.
• გამოშვების ვერსიების ავტომატური შემოწმება maven Central-ში გამოსაქვეყნებლად.
• ზოგადი გადაწყვეტა მრავალი პროექტისთვის არტეფაქტების საცავში ატვირთვისთვის.
• სიმარტივე და გამოყენების სიმარტივე.

ინფორმაციის

• ზოგადი ინფორმაცია
• GitLab-ში განლაგების პროექტის დაყენება
• GitLab Runner
  • სპეციფიკური მორბენალი
    • gitlab runner-ის დაყენება
    • GPG გასაღების გენერაცია
    • Maven-ის დაყენება
  • გაზიარებული მორბენალი
    • GPG გასაღების გენერაცია
    • Maven-ის დაყენება
    • განათავსეთ დოკერის სურათი
• GitLab CI
  • განათავსეთ პროექტი
  • ჯავის პროექტი
• pom.xml კონფიგურაცია
  • maven-install-plugin
  • maven-javadoc-პლაგინი
  • maven-gpg-მოდული
  • nexus-staging-maven-plugin
• შედეგი
  • სნეპშოტის ვერსიის გამოქვეყნება
  • გამოშვების ვერსიის გამოქვეყნება
• დასკვნა

ზოგადი ინფორმაცია

• Sonatype OSS საცავის ჰოსტინგის სერვისის მეშვეობით Maven Central-ში არტეფაქტების გამოქვეყნების მექანიზმის დეტალური აღწერა უკვე აღწერილია ეს არტიკლი მომხმარებელი გუგოლპლექსი, ამიტომ ამ სტატიას სწორ ადგილებში მივმართავ.
• წინასწარ ჩაწერა მისამართზე სონატიპი JIRA და დაიწყეთ ბილეთი საცავის გასახსნელად (დამატებითი ინფორმაციისთვის წაიკითხეთ განყოფილება შექმენით Sonatype JIRA ბილეთი). საცავის გახსნის შემდეგ, JIRA შესვლა/პაროლის წყვილი (შემდგომში Sonatype ანგარიში) გამოყენებული იქნება არტეფაქტების ასატვირთად Sonatype Nexus-ში.
• შემდეგი, GPG გასაღების გენერირების პროცესი ძალიან მშრალად არის აღწერილი. იხილეთ სექცია დამატებითი დეტალებისთვის GnuPG-ის კონფიგურაცია არტეფაქტების ხელმოწერისთვის
• თუ თქვენ იყენებთ Linux კონსოლს GPG გასაღების შესაქმნელად (gnupg/gnupg2), მაშინ უნდა დააინსტალიროთ rng- ინსტრუმენტები ენტროპიის შესაქმნელად. წინააღმდეგ შემთხვევაში, გასაღების შექმნას შეიძლება ძალიან დიდი დრო დასჭირდეს.
• შენახვის სერვისები საზოგადოება GPG კლავიშები
  • http://keys.gnupg.net
  • http://pool.sks-keyservers.net
  • http://keyserver.ubuntu.com

შინაარსით

GitLab-ში განლაგების პროექტის დაყენება

• უპირველეს ყოვლისა, თქვენ უნდა შექმნათ და დააკონფიგურიროთ პროექტი, რომელშიც მილსადენი შეინახება არტეფაქტების განლაგებისთვის. მე ვუწოდე ჩემს პროექტს მარტივად და გაურთულებლად - განათავსოს
• საცავის შექმნის შემდეგ, თქვენ უნდა შეზღუდოთ წვდომა საცავის შესაცვლელად.
  გადადით პროექტზე -> პარამეტრები -> საცავი -> დაცული ფილიალები. ჩვენ ვშლით ყველა წესს და ვამატებთ ერთ წესს Wildcard *-ით, უფლებით დააყენოს და შერწყმა მხოლოდ იმ მომხმარებლებისთვის, რომლებსაც აქვთ Maintainers როლი. ეს წესი იმუშავებს როგორც ამ პროექტის, ასევე იმ ჯგუფის ყველა მომხმარებლისთვის, რომელსაც ეკუთვნის ეს პროექტი.
  
• თუ არსებობს რამდენიმე შემსრულებელი, მაშინ საუკეთესო გამოსავალი იქნება პრინციპში პროექტზე წვდომის შეზღუდვა.
  გადადით პროექტზე -> პარამეტრები -> ზოგადი -> ხილვადობა, პროექტის ფუნქციები, ნებართვები და დააყენეთ პროექტის ხილვადობა პირადი.
  მე მაქვს პროექტი საჯარო წვდომაში, რადგან ვიყენებ ჩემს GitLab Runner-ს და მხოლოდ მე მაქვს წვდომა საცავის შეცვლაზე. ისე, რეალურად არ შედის ჩემს ინტერესებში პირადი ინფორმაციის ჩვენება საჯარო მილსადენის ჟურნალებში.
• საცავის შეცვლის წესების გამკაცრება
  გადადით პროექტზე -> Settings -> Repository -> Push Rules და დააყენეთ Committer-ის შეზღუდვა, შეამოწმეთ არის თუ არა ავტორი GitLab მომხმარებლის დროშები. მე ასევე გირჩევთ დაყენებას ხელმოწერის ვალდებულებადა დააყენეთ Reject unsigned commits flag.
• შემდეგი, თქვენ უნდა დააკონფიგურიროთ ტრიგერი ამოცანების შესასრულებლად
  გადადით პროექტზე -> პარამეტრები -> CI / CD -> მილსადენის ტრიგერები და შექმენით ახალი ტრიგერი-ტოკენი
  ეს ნიშანი შეიძლება დაუყოვნებლივ დაემატოს ცვლადების ზოგად კონფიგურაციას პროექტების ჯგუფისთვის.
  გადადით ჯგუფში -> პარამეტრები -> CI / CD -> ცვლადები და დაამატეთ ცვლადი DEPLOY_TOKEN ტრიგერ-ტოკენით მნიშვნელობაში.

შინაარსით

GitLab Runner

ეს განყოფილება აღწერს კონფიგურაციას გაშვებული ამოცანების განლაგებისას მშობლიური (სპეციფიკური) და საჯარო (გაზიარებული) runner-ის გამოყენებით.

სპეციფიკური მორბენალი

მე ვიყენებ საკუთარ მორბენალს, რადგან, პირველ რიგში, ეს არის მოსახერხებელი, სწრაფი და იაფი.
runner-ისთვის გირჩევთ Linux VDS-ს 1 CPU, 2 GB ოპერატიული, 20 GB HDD. გამოშვების ფასი ~ 3000₽ წელიწადში.

ჩემი მორბენალი

მორბენალისთვის ავიღე VDS 4 CPU, 4 GB RAM, 50 GB SSD. ღირდა ~ 11000₽ და არასდროს მინანია.
სულ 7 მანქანა მაქვს. 5 არუბაზე და 2 იჰორზე.

ასე რომ, ჩვენ გვყავს მორბენალი. ახლა ჩვენ დავაყენებთ მას.
ჩვენ მივდივართ მანქანაში SSH-ის საშუალებით და ვაყენებთ java, git, maven, gnupg2.

შინაარსით

gitlab runner-ის დაყენება

• შექმენით ახალი ჯგუფი runner

  sudo groupadd runner

• შექმენით დირექტორია maven ქეშისთვის და მიანიჭეთ ჯგუფის უფლებები runner
  თქვენ შეგიძლიათ გამოტოვოთ ეს ნაბიჯი, თუ არ გეგმავთ რამდენიმე მორბენალის გაშვებას იმავე მანქანაზე.

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

• შექმენით მომხმარებელი gitlab-deployer და დაამატეთ ჯგუფს runner

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

• ფაილში დამატება /etc/ssh/sshd_config შემდეგი ხაზი

  AllowUsers root@* [email protected]

• გადატვირთვა sshd

  systemctl restart sshd

• დააყენეთ პაროლი მომხმარებლისთვის gitlab-deployer (ეს შეიძლება იყოს მარტივი, რადგან არსებობს შეზღუდვა localhost-ისთვის)

  passwd gitlab-deployer

• დააინსტალირეთ 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

• გადადით gitlab.com -> deploy-project -> Settings -> CI/CD -> Runners -> Specific Runners და დააკოპირეთ რეგისტრაციის ჟეტონი

ეკრანი

• მორბენალის რეგისტრაცია

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

პროცესი

Runtime platform arch=amd64 os=linux pid=17594 revision=3001a600 version=11.10.0
Running in system-mode.
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
https://gitlab.com/
Please enter the gitlab-ci token for this runner:
REGISTRATION_TOKEN
Please enter the gitlab-ci description for this runner:
[ih1174328.vds.myihor.ru]: Deploy Runner
Please enter the gitlab-ci tags for this runner (comma separated):
deploy
Registering runner... succeeded                     runner=ZvKdjJhx
Please enter the executor: docker-ssh, parallels, virtualbox, docker-ssh+machine, kubernetes, docker, ssh, docker+machine, shell:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

• შეამოწმეთ, რომ მორბენალი რეგისტრირებულია. გადადით gitlab.com -> deploy-project -> Settings -> CI/CD -> Runners -> Specific Runners -> Runners გააქტიურებული ამ პროექტისთვის

ეკრანი

• დამატება ცალკე მომსახურება /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

• ჩვენ ვიწყებთ მომსახურებას.

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

• შეამოწმეთ, რომ მორბენალი დარბის.

მაგალითი

შინაარსით

GPG გასაღების გენერაცია

• იგივე აპარატიდან ჩვენ მივდივართ ssh-ით მომხმარებლის ქვეშ gitlab-deployer (ეს მნიშვნელოვანია GPG გასაღების გენერირებისთვის)

  ssh [email protected]

• ჩვენ ვქმნით გასაღებს კითხვებზე პასუხის გაცემით. გამოვიყენე ჩემი სახელი და ელ.წერილი.
  დარწმუნდით, რომ მიუთითეთ გასაღების პაროლი. ამ გასაღებით ხელმოწერილი იქნება არტეფაქტები.

  gpg --gen-key 

• შემოწმება

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

• ჩვენი საჯარო გასაღების ატვირთვა გასაღების სერვერზე

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

შინაარსით

Maven-ის დაყენება

• ჩვენ მივდივართ მომხმარებლის ქვეშ gitlab-deployer

  su gitlab-deployer 

• შექმენით maven დირექტორია საცავი და დააკავშირეთ ქეშთან (არ შეცდეთ)
  ეს ნაბიჯი შეიძლება გამოტოვოთ, თუ არ აპირებთ რამდენიმე მორბენალის გაშვებას იმავე მანქანაზე.

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

• შექმენით ძირითადი გასაღები

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

• შექმენით ფაილი ~/.m2/settings-security.xml

  <settingsSecurity>
  <master>{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}</master>
  </settingsSecurity>

• პაროლის დაშიფვრა Sonatype ანგარიშიდან

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

• შექმენით ფაილი ~/.m2/settings.xml

  <settings>  
  <profiles>
      <profile>
          <id>env</id>
          <activation>
              <activeByDefault>true</activeByDefault>
          </activation>
          <properties>
              <gpg.passphrase>GPG_SECRET_KEY_PASSPHRASE</gpg.passphrase>
          </properties>
      </profile>
  </profiles>
  <servers>
      <server>
          <id>sonatype</id>
          <username>SONATYPE_USERNAME</username>
          <password>{98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}</password>
      </server>
  </servers>
  </settings>

სად,
GPG_SECRET_KEY_PASSPHRASE - GPG გასაღების პაროლი
SONATYPE_USERNAME — sonatype ანგარიშის შესვლა

ეს დაასრულებს runner-ის დაყენებას, შეგიძლიათ გადახვიდეთ განყოფილებაში GitLab CI

შინაარსით

გაზიარებული მორბენალი

GPG გასაღების გენერაცია

• უპირველეს ყოვლისა, თქვენ უნდა შექმნათ GPG გასაღები. ამისათვის დააინსტალირეთ gnupg.

  yum install -y gnupg

• ჩვენ ვქმნით გასაღებს კითხვებზე პასუხის გაცემით. გამოვიყენე ჩემი სახელი და ელ.წერილი. დარწმუნდით, რომ მიუთითეთ გასაღების პაროლი.

  gpg --gen-key 

• კლავიშზე ინფორმაციის ჩვენება

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

• ჩვენი საჯარო გასაღების ატვირთვა გასაღების სერვერზე

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

• პირადი გასაღების მიღება

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

• გადადით პროექტის პარამეტრებში -> პარამეტრები -> CI / CD -> ცვლადები და შეინახეთ პირადი გასაღები ცვლადში GPG_SECRET_KEY
  

შინაარსით

Maven-ის დაყენება

• შექმენით ძირითადი გასაღები

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

• გადადით პროექტის პარამეტრებში -> პარამეტრები -> CI / CD -> ცვლადები და შეინახეთ ცვლადში SETTINGS_SECURITY_XML შემდეგი ხაზები:

  <settingsSecurity>
  <master>{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}</master>
  </settingsSecurity>

• პაროლის დაშიფვრა Sonatype ანგარიშიდან

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

• გადადით პროექტის პარამეტრებში -> პარამეტრები -> CI / CD -> ცვლადები და შეინახეთ ცვლადში SETTINGS_XML შემდეგი ხაზები:

  <settings>  
  <profiles>
      <profile>
          <id>env</id>
          <activation>
              <activeByDefault>true</activeByDefault>
          </activation>
          <properties>
              <gpg.passphrase>GPG_SECRET_KEY_PASSPHRASE</gpg.passphrase>
          </properties>
      </profile>
  </profiles>
  <servers>
      <server>
          <id>sonatype</id>
          <username>sonatype_username</username>
          <password>{98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}</password>
      </server>
  </servers>
  </settings>

სად,
GPG_SECRET_KEY_PASSPHRASE - GPG გასაღების პაროლი
SONATYPE_USERNAME — sonatype ანგარიშის შესვლა

შინაარსით

განათავსეთ დოკერის სურათი

• ჩვენ ვქმნით საკმაოდ მარტივ Dockerfile-ს დავალებების გასაშვებად Java-ს სასურველი ვერსიით. ქვემოთ მოცემულია მაგალითი ალპურისთვის.

  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/

• კონტეინერის აწყობა თქვენი პროექტისთვის

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

• ჩვენ ვამოწმებთ ავთენტიფიკაციას და ვტვირთავთ კონტეინერს რეესტრში.

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

შინაარსით

GitLab CI

განათავსეთ პროექტი

დაამატეთ ფაილი .gitlab-ci.yml განლაგების პროექტის ძირში
სკრიპტი წარმოადგენს ორ ურთიერთგამომრიცხავ განლაგების ამოცანას. კონკრეტული Runner ან Shared Runner შესაბამისად.

.gitlab-ci.yml

stages:
  - deploy

Specific Runner:
  extends: .java_deploy_template
  # Задача будет выполняться на вашем shell-раннере
  tags:
    - deploy

Shared Runner:
  extends: .java_deploy_template
  # Задача будет выполняться на публичном docker-раннере
  tags:
    - docker
  # Образ из раздела GitLab Runner -> Shared Runner -> Docker
  image: registry.gitlab.com/group/deploy-project:latest
  before_script:
    # Импортируем GPG ключ
    - printf "${GPG_SECRET_KEY}" | gpg --batch --import
    # Сохраняем maven конфигурацию
    - printf "${SETTINGS_SECURITY_XML}" > ~/.m2/settings-security.xml
    - printf "${SETTINGS_XML}" > ~/.m2/settings.xml

.java_deploy_template:
  stage: deploy
  # Задача сработает по триггеру, если передана переменная DEPLOY со значением java
  only:
    variables:
    - $DEPLOY == "java"
  variables:
    # отключаем клонирование текущего проекта
    GIT_STRATEGY: none
  script:
    # Предоставляем возможность хранения пароля в незашифрованном виде
    - git config --global credential.helper store
    # Сохраняем временные креды пользователя gitlab-ci-token
    # Токен работает для всех публичных проектов gitlab.com и для проектов группы
    - echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" >> ~/.git-credentials
    # Полностью чистим текущую директорию
    - rm -rf .* *
    # Клонируем проект который, будем деплоить в Sonatype Nexus
    - git clone ${DEPLOY_CI_REPOSITORY_URL} .
    # Переключаемся на нужный коммит
    - git checkout ${DEPLOY_CI_COMMIT_SHA} -f
    # Если хоть один pom.xml содержит параметр autoReleaseAfterClose валим сборку.
    # В противном случае есть риск залить сырые артефакты в maven central
    - >
      for pom in $(find . -name pom.xml); do
        if [[ $(grep -q autoReleaseAfterClose "$pom" && echo $?) == 0 ]]; then
          echo "File $pom contains prohibited setting: <autoReleaseAfterClose>";
          exit 1;
        fi;
      done
    # Если параметр DEPLOY_CI_COMMIT_TAG пустой, то принудительно ставим 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
    # Запускаем задачу на сборку и деплой артефактов
    - mvn clean deploy -DskipTests=true

შინაარსით

ჯავის პროექტი

java პროექტებში, რომლებიც უნდა აიტვირთოს საჯარო საცავებში, თქვენ უნდა დაამატოთ 2 ნაბიჯი გამოშვებისა და Snapshot ვერსიების ჩამოსატვირთად.

.gitlab-ci.yml

stages:
  - build
  - test
  - verify
  - deploy

<...>

Release:
  extends: .trigger_deploy
  # Запускать задачу только пo тегу.
  only:
    - tags

Snapshot:
  extends: .trigger_deploy
  # Запускаем задачу на публикацию SNAPSHOT версии вручную
  when: manual
  # Не запускать задачу, если проставлен тег.
  except:
    - tags

.trigger_deploy:
  stage: deploy
  variables:
    # Отключаем клонирование текущего проекта
    GIT_STRATEGY: none
    # Ссылка на триггер deploy-задачи
    URL: "https://gitlab.com/api/v4/projects/<deploy project ID>/trigger/pipeline"
    # Переменные deploy-задачи
    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:
    # Не использую cURL, так как с флагами --fail --show-error
    # он не выводит тело ответа, если HTTP код 400 и более 
    - wget --content-on-error -qO- ${URL} --post-data ${POST_DATA}

ამ გადაწყვეტაში, მე ცოტა უფრო შორს წავედი და გადავწყვიტე გამომეყენებინა ერთი CI შაბლონი java პროექტებისთვის.

დაწვრილებით

ცალკე პროექტი შევქმენი გიტლაბ-ცი რომელშიც მან მოათავსა CI შაბლონი java პროექტებისთვის საერთო.yml.

საერთო.yml

stages:
  - build
  - test
  - verify
  - deploy

variables:
  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 day
    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 day
    paths:
      - "*/target/reports"

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

.sonar_review:
  stage: verify
  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: 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

შედეგად, თავად java პროექტებში .gitlab-ci.yml გამოიყურება ძალიან კომპაქტური და არა სიტყვიერი

.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

შინაარსით

pom.xml კონფიგურაცია

ეს თემა დეტალურად არის აღწერილი. გუგოლპლექსი в Maven-ის დაყენება, რათა ავტომატურად მოაწეროს ხელი და ატვირთოს არტეფაქტები სნეპშოტებისა და დადგმის საცავებში, ასე რომ, მე აღვწერ დანამატების გამოყენების ზოგიერთ ნიუანსს. მე ასევე აღვწერ, რამდენად მარტივი და მოდუნებული შეგიძლიათ გამოიყენოთ nexus-staging-maven-pluginთუ არ გსურთ ან არ შეგიძლიათ გამოიყენოთ org.sonatype.oss:oss-parent, როგორც მშობელი თქვენი პროექტისთვის.

maven-install-plugin

აინსტალირებს მოდულებს ადგილობრივ საცავში.
ძალიან სასარგებლოა სხვა პროექტებში გადაწყვეტილებების ადგილობრივი გადამოწმებისთვის, ასევე საკონტროლო ჯამისთვის.

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-install-plugin</artifactId>
  <executions>
    <execution>
      <id>install-project</id>
      <!-- Если у вас многомодульный проект с деплоем родительского помика -->
      <phase>install</phase>
      <!-- Явно указываем файлы для локальной установки -->
      <configuration>
        <file>target/${project.artifactId}-${project.version}.jar</file>
```target/${project.artifactId}-${project.version}-sources.jar</sources>
        <pomFile>dependency-reduced-pom.xml</pomFile>
        <!-- Принудительное обновление метаданных проекта -->
        <updateReleaseInfo>true</updateReleaseInfo>
        <!-- Контрольные суммы для проверки целостности -->
        <createChecksum>true</createChecksum>
      </configuration>
    </execution>
  </executions>
</plugin>

შინაარსით

maven-javadoc-პლაგინი

javadoc-ის გენერირება პროექტისთვის.

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-javadoc-plugin</artifactId>
  <executions>
    <execution>
      <goals>
        <goal>jar</goal>
      </goals>
      <!-- Генерация javadoc должна быть после фазы генерации ресурсов -->
      <phase>prepare-package</phase>
      <configuration>
        <!-- Очень помогает в публичных проектах -->
        <failOnError>true</failOnError>
        <failOnWarnings>true</failOnWarnings>
        <!-- Убирает ошибку поиска документации в target директории -->
        <detectOfflineLinks>false</detectOfflineLinks>
      </configuration>
    </execution>
  </executions>
</plugin>

თუ თქვენ გაქვთ მოდული, რომელიც არ შეიცავს ჯავას (მაგალითად მხოლოდ რესურსებს)
ან პრინციპში არ გინდა ჯავადოკის გენერირება, მერე დაეხმარე maven-jar-plugin

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-jar-plugin</artifactId>
  <executions>
    <execution>
      <id>empty-javadoc-jar</id>
      <phase>generate-resources</phase>
      <goals>
        <goal>jar</goal>
      </goals>
      <configuration>
        <classifier>javadoc</classifier>
        <classesDirectory>${basedir}/javadoc</classesDirectory>
      </configuration>
    </execution>
  </executions>
</plugin>

შინაარსით

maven-gpg-მოდული

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-gpg-plugin</artifactId>
  <executions>
    <execution>
      <id>sign-artifacts</id>
      <!-- Сборка будет падать, если отсутствует GPG ключ -->
      <!-- Подписываем артефакты только на фазе deploy -->
      <phase>deploy</phase>
      <goals>
        <goal>sign</goal>
      </goals>
    </execution>
  </executions>
</plugin>

შინაარსით

nexus-staging-maven-plugin

კონფიგურაცია:

<project>
  <!-- ... -->
  <build>
    <plugins>
      <!-- ... -->
      <plugin>
        <groupId>org.sonatype.plugins</groupId>
        <artifactId>nexus-staging-maven-plugin</artifactId>
      </plugin>
    </plugins>
    <pluginManagement>
      <plugins>
        <plugin>
          <groupId>org.sonatype.plugins</groupId>
          <artifactId>nexus-staging-maven-plugin</artifactId>
          <extensions>true</extensions>
          <configuration>
            <serverId>sonatype</serverId>
            <nexusUrl>https://oss.sonatype.org/</nexusUrl>
            <!-- Обновляем метаданные, чтобы пометить артефакт как release -->
            <!-- Не влияет на snapshot версии -->
            <updateReleaseInfo>true</updateReleaseInfo>
          </configuration>
        </plugin>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-deploy-plugin</artifactId>
          <configuration>
            <!-- Отключаем плагин -->
            <skip>true</skip>
          </configuration>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>
  <distributionManagement>
    <snapshotRepository>
      <id>sonatype</id>
      <name>Nexus Snapshot Repository</name>
      <url>https://oss.sonatype.org/content/repositories/snapshots/</url>
    </snapshotRepository>
    <repository>
      <id>sonatype</id>
      <name>Nexus Release Repository</name>
      <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
    </repository>
  </distributionManagement>
</project>

თუ თქვენ გაქვთ მრავალმოდული პროექტი და არ გჭირდებათ კონკრეტული მოდულის ატვირთვა საცავში, მაშინ უნდა დაამატოთ ამ მოდულის pom.xml nexus-staging-maven-plugin დროშით skipNexusStagingDeployMojo

<build>
  <plugins>
    <plugin>
      <groupId>org.sonatype.plugins</groupId>
      <artifactId>nexus-staging-maven-plugin</artifactId>
      <configuration>
        <skipNexusStagingDeployMojo>true</skipNexusStagingDeployMojo>
      </configuration>
    </plugin>
  </plugins>
</build>

ატვირთვის შემდეგ, სნეპშოტის/გამოშვების ვერსიები ხელმისაწვდომია საცავების დადგმა

<repositories>
  <repository>
    <id>SonatypeNexus</id>
    <url>https://oss.sonatype.org/content/groups/staging/</url>
    <!-- Не надо указывать флаги snapshot/release для репозитория -->
  </repository>
</repositories>

მეტი პლიუსი

• მიზნების ძალიან მდიდარი სია nexus საცავთან მუშაობისთვის (mvn help:describe -Dplugin=org.sonatype.plugins:nexus-staging-maven-plugin).
• ავტომატური გამოშვების შემოწმება ჩამოტვირთვის შესაძლებლობისთვის Maven Central-ში

შინაარსით

შედეგი

SNAPSHOT ვერსიის გამოქვეყნება

პროექტის შექმნისას შესაძლებელია დავალების ხელით დაწყება SNAPSHOT ვერსიის nexus-ში ჩამოსატვირთად

როდესაც ეს ამოცანა ამოქმედდება, შესაბამისი დავალება ამოქმედდება განლაგების პროექტში (მაგალითად).

მოჭრილი ჟურნალი

Running with gitlab-runner 11.10.0 (3001a600)
  on Deploy runner JSKWyxUw
Using Shell executor...
Running on ih1174328.vds.myihor.ru...
Skipping Git repository setup
Skipping Git checkout
Skipping Git submodules setup
$ 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} .
Cloning into 'shields4j'...
$ git checkout ${DEPLOY_CI_COMMIT_SHA}
Note: checking out '850f86aa317194395c5387790da1350e437125a7'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
  git checkout -b new_branch_name
HEAD is now at 850f86a... skip deploy test-core
$ for pom in $(find . -name pom.xml); do # collapsed multi-line command
$ if [[ "${DEPLOY_CI_COMMIT_TAG}" != "" ]]; then # collapsed multi-line command
[INFO] Scanning for projects...
[INFO] Inspecting build with total of 4 modules...
[INFO] Installing Nexus Staging features:
[INFO]   ... total of 4 executions of maven-deploy-plugin replaced with nexus-staging-maven-plugin
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO] 
[INFO] Shields4J                                                          [pom]
[INFO] test-core                                                          [jar]
[INFO] Shields4J client                                                   [jar]
[INFO] TestNG listener                                                    [jar]
[INFO] 
[INFO] --------------< org.touchbit.shields4j:shields4j-parent >---------------
[INFO] Building Shields4J 1.0.0                                           [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
[INFO] 
[INFO] --- versions-maven-plugin:2.5:set (default-cli) @ shields4j-parent ---
[INFO] Searching for local aggregator root...
[INFO] Local aggregation root: /home/gitlab-deployer/JSKWyxUw/0/TouchBIT/deploy/shields4j
[INFO] Processing change of org.touchbit.shields4j:shields4j-parent:1.0.0 -> 1.0.0-SNAPSHOT
[INFO] Processing org.touchbit.shields4j:shields4j-parent
[INFO]     Updating project org.touchbit.shields4j:shields4j-parent
[INFO]         from version 1.0.0 to 1.0.0-SNAPSHOT
[INFO] 
[INFO] Processing org.touchbit.shields4j:client
[INFO]     Updating parent org.touchbit.shields4j:shields4j-parent
[INFO]         from version 1.0.0 to 1.0.0-SNAPSHOT
[INFO]     Updating dependency org.touchbit.shields4j:test-core
[INFO]         from version 1.0.0 to 1.0.0-SNAPSHOT
[INFO] 
[INFO] Processing org.touchbit.shields4j:test-core
[INFO]     Updating parent org.touchbit.shields4j:shields4j-parent
[INFO]         from version 1.0.0 to 1.0.0-SNAPSHOT
[INFO] 
[INFO] Processing org.touchbit.shields4j:testng
[INFO]     Updating parent org.touchbit.shields4j:shields4j-parent
[INFO]         from version 1.0.0 to 1.0.0-SNAPSHOT
[INFO]     Updating dependency org.touchbit.shields4j:client
[INFO]         from version 1.0.0 to 1.0.0-SNAPSHOT
[INFO]     Updating dependency org.touchbit.shields4j:test-core
[INFO]         from version 1.0.0 to 1.0.0-SNAPSHOT
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] Shields4J 1.0.0 .................................... SUCCESS [  0.992 s]
[INFO] test-core .......................................... SKIPPED
[INFO] Shields4J client ................................... SKIPPED
[INFO] TestNG listener 1.0.0 .............................. SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.483 s
[INFO] Finished at: 2019-04-21T02:40:42+03:00
[INFO] ------------------------------------------------------------------------
$ mvn clean deploy -DskipTests=${SKIP_TESTS}
[INFO] Scanning for projects...
[INFO] Inspecting build with total of 4 modules...
[INFO] Installing Nexus Staging features:
[INFO]   ... total of 4 executions of maven-deploy-plugin replaced with nexus-staging-maven-plugin
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO] 
[INFO] Shields4J                                                          [pom]
[INFO] test-core                                                          [jar]
[INFO] Shields4J client                                                   [jar]
[INFO] TestNG listener                                                    [jar]
[INFO] 
[INFO] --------------< org.touchbit.shields4j:shields4j-parent >---------------
[INFO] Building Shields4J 1.0.0-SNAPSHOT                                  [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
...
DELETED
...
[INFO]  * Bulk deploy of locally gathered snapshot artifacts finished.
[INFO] Remote deploy finished with success.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] Shields4J 1.0.0-SNAPSHOT ........................... SUCCESS [  2.375 s]
[INFO] test-core .......................................... SUCCESS [  3.929 s]
[INFO] Shields4J client ................................... SUCCESS [  3.815 s]
[INFO] TestNG listener 1.0.0-SNAPSHOT ..................... SUCCESS [ 36.134 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 47.629 s
[INFO] Finished at: 2019-04-21T02:41:32+03:00
[INFO] ------------------------------------------------------------------------

შედეგად, nexus ვერსია იტვირთება 1.0.0-SNAPSHOT.

ყველა სნეფშოტის ვერსია შეიძლება წაიშალოს საიტის საცავიდან oss.sonatype.org თქვენი ანგარიშის ქვეშ.

შინაარსით

გამოშვების ვერსიის გამოქვეყნება

როდესაც ტეგი დაყენებულია, განლაგების პროექტში შესაბამისი დავალება ავტომატურად ამოქმედდება გამოშვების ვერსიის ატვირთვისთვის nexus-ში (მაგალითად).

საუკეთესო ნაწილი ის არის, რომ დახურვის გამოშვება ავტომატურად ამოქმედდება Nexus-ში.

[INFO] Performing remote staging...
[INFO] 
[INFO]  * Remote staging into staging profile ID "9043b43f77dcc9"
[INFO]  * Created staging repository with ID "orgtouchbit-1037".
[INFO]  * Staging repository at https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1037
[INFO]  * Uploading locally staged artifacts to profile org.touchbit
[INFO]  * Upload of locally staged artifacts finished.
[INFO]  * Closing staging repository with ID "orgtouchbit-1037".
Waiting for operation to complete...
.........
[INFO] Remote staged 1 repositories, finished with success.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] Shields4J 1.0.0 .................................... SUCCESS [  9.603 s]
[INFO] test-core .......................................... SUCCESS [  3.419 s]
[INFO] Shields4J client ................................... SUCCESS [  9.793 s]
[INFO] TestNG listener 1.0.0 .............................. SUCCESS [01:23 min]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 01:47 min
[INFO] Finished at: 2019-04-21T04:05:46+03:00
[INFO] ------------------------------------------------------------------------

და თუ რამე არასწორედ წარიმართა, მაშინ დავალება ჩავარდება

[INFO] Performing remote staging...
[INFO] 
[INFO]  * Remote staging into staging profile ID "9043b43f77dcc9"
[INFO]  * Created staging repository with ID "orgtouchbit-1038".
[INFO]  * Staging repository at https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1038
[INFO]  * Uploading locally staged artifacts to profile org.touchbit
[INFO]  * Upload of locally staged artifacts finished.
[INFO]  * Closing staging repository with ID "orgtouchbit-1038".
Waiting for operation to complete...
.......
[ERROR] Rule failure while trying to close staging repository with ID "orgtouchbit-1039".
[ERROR] 
[ERROR] Nexus Staging Rules Failure Report
[ERROR] ==================================
[ERROR] 
[ERROR] Repository "orgtouchbit-1039" failures
[ERROR]   Rule "signature-staging" failures
[ERROR]     * No public key: Key with id: (1f42b618d1cbe1b5) was not able to be located on <a href=http://keys.gnupg.net:11371/>http://keys.gnupg.net:11371/</a>. Upload your public key and try the operation again.
...
[ERROR] Cleaning up local stage directory after a Rule failure during close of staging repositories: [orgtouchbit-1039]
[ERROR]  * Deleting context 9043b43f77dcc9.properties
[ERROR] Cleaning up remote stage repositories after a Rule failure during close of staging repositories: [orgtouchbit-1039]
[ERROR]  * Dropping failed staging repository with ID "orgtouchbit-1039" (Rule failure during close of staging repositories: [orgtouchbit-1039]).
[ERROR] Remote staging finished with a failure: Staging rules failure!
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] Shields4J 1.0.0 .................................... SUCCESS [  4.073 s]
[INFO] test-core .......................................... SUCCESS [  2.788 s]
[INFO] Shields4J client ................................... SUCCESS [  3.962 s]
[INFO] TestNG listener 1.0.0 .............................. FAILURE [01:07 min]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------

შედეგად, ჩვენ მხოლოდ ერთი არჩევანი გვრჩება. ან წაშალე ეს ვერსია ან გამოაქვეყნე.

გამოშვების შემდეგ, გარკვეული პერიოდის შემდეგ, არტეფაქტები იქნება

ოფტოპიკი

ეს იყო ჩემთვის აღმოჩენა, რომ maven ინდექსებს სხვა საჯარო საცავებს.
მომიწია robots.txt ატვირთვა, რადგან მან მოახდინა ჩემი ძველი საცავი.

შინაარსით

დასკვნა

რაც გვაქვს

• ცალკე განლაგების პროექტი, რომელშიც შეგიძლიათ განახორციელოთ რამდენიმე CI დავალება არტეფაქტების ატვირთვისთვის საჯარო საცავებში განვითარების სხვადასხვა ენებისთვის.
• განლაგების პროექტი იზოლირებულია გარე ჩარევისგან და შეიძლება შეიცვალოს მხოლოდ მფლობელის და შემსრულებლის როლების მქონე მომხმარებლების მიერ.
• ცალკე სპეციფიური Runner „ცხელი“ ქეშით მხოლოდ ამოცანების განლაგების მიზნით.
• სნეპშოტის/გამოშვების ვერსიების გამოქვეყნება საჯარო საცავში.
• გამოშვების ვერსიის ავტომატური შემოწმება Maven Central-ში გამოსაქვეყნებლად მზადყოფნისთვის.
• დაცვა Maven Central-ში „ნედლეული“ ვერსიების ავტომატური გამოქვეყნებისგან.
• შექმენით და გამოაქვეყნეთ სნეპშოტის ვერსიები "დაწკაპუნებით".
• ერთიანი საცავი სნეპშოტის/გამოშვების ვერსიების მისაღებად.
• ზოგადი მილსადენი Java-პროექტის მშენებლობის / ტესტირების / გამოქვეყნებისთვის.

GitLab CI-ის დაყენება არც ისე რთული თემაა, როგორც ერთი შეხედვით ჩანს. საკმარისია რამდენჯერმე დააყენოთ CI ანაზრაურების საფუძველზე და ახლა თქვენ შორს ხართ ამ საკითხში მოყვარულისგან. უფრო მეტიც, GitLab დოკუმენტაცია ძალიან ზედმეტია. ნუ შეგეშინდებათ პირველი ნაბიჯის გადადგმის. გზა მოსიარულეს ნაბიჯების ქვეშ ჩნდება (არ მახსოვს ვინ თქვა :)

სიამოვნებით მივიღებ გამოხმაურებას.

შემდეგ სტატიაში მე ვისაუბრებ იმაზე, თუ როგორ უნდა დააკონფიგურიროთ GitLab CI, რათა ამოცანები შეასრულოს ინტეგრაციის ტესტებით კონკურენტულად (გამოსაცდელი სერვისების გაშვება docker-compose-ის გამოყენებით), თუ მხოლოდ ერთი ჭურვი გაქვთ.

შინაარსით

წყარო: www.habr.com