Tento článek je určen pro java vývojáře, kteří potřebují rychle publikovat své produkty do centrálních repozitářů sonatype a/nebo maven pomocí GitLabu. V tomto článku budu hovořit o nastavení gitlab-runner, gitlab-ci a maven-plugin k vyřešení tohoto problému.
Předpoklady:
- Bezpečné uložení klíčů mvn a GPG.
- Bezpečné provádění úkolů veřejné CI.
- Nahrávání artefaktů (vydání/snímek) do veřejných úložišť.
- Automatická kontrola verzí pro zveřejnění v maven central.
- Obecné řešení pro nahrávání artefaktů do úložiště pro více projektů.
- Jednoduchost a snadné použití.
Obsah
Všeobecné informace
- Podrobný popis mechanismu pro publikování artefaktů do Maven Central přes Sonatype OSS Repository Hosting Service je již popsán v uživatel , tak budu odkazovat na tento článek na správných místech.
- Předběžně se zaregistrujte na a spusťte lístek pro otevření úložiště (pro více podrobností si přečtěte sekci ). Po otevření úložiště bude dvojice login/heslo JIRA (dále jen účet Sonatype) použita k nahrání artefaktů na nexus Sonatype.
- Dále je velmi suše popsán proces generování GPG klíče. Další podrobnosti naleznete v části.
- Pokud ke generování klíče GPG (gnupg/gnupg2) používáte konzolu Linux, musíte nainstalovat generovat entropii. V opačném případě může generování klíče trvat velmi dlouho.
- Skladovací služby veřejnost GPG klíče
Nastavení projektu nasazení v GitLabu
- Nejprve je potřeba vytvořit a nakonfigurovat projekt, ve kterém bude uložen pipeline pro nasazení artefaktů. Svůj projekt jsem nazval jednoduše a nekomplikovaně -
- Po vytvoření úložiště musíte omezit přístup, abyste mohli úložiště změnit.
Přejděte do projektu -> Nastavení -> Úložiště -> Chráněné větve. Odstraníme všechna pravidla a přidáme jediné pravidlo se zástupným znakem * s právem push a sloučení pouze pro uživatele s rolí Správci. Toto pravidlo bude fungovat pro všechny uživatele tohoto projektu i skupiny, do které tento projekt patří.
- Pokud existuje několik správců, pak by nejlepším řešením bylo zásadně omezit přístup k projektu.
Přejděte do projektu -> Nastavení -> Obecné -> Viditelnost, funkce projektu, oprávnění a nastavte Viditelnost projektu na soukromý.
Mám projekt ve veřejném přístupu, protože používám svůj vlastní GitLab Runner a pouze já mám přístup k úpravě úložiště. No, vlastně není v mém zájmu ukazovat soukromé informace ve veřejných protokolech potrubí. - Zpřísnění pravidel pro změnu úložiště
Přejděte do projektu -> Nastavení -> Úložiště -> Pravidla Push a nastavte příznaky Omezení komisí, Zkontrolujte, zda je autor uživatelem GitLab. Doporučuji také nastavit a nastavte příznak Odmítnout nepodepsané potvrzení. - Dále musíte nakonfigurovat spouštěč pro spouštění úloh
Přejděte do Project -> Settings -> CI / CD -> Pipeline triggers a vytvořte nový trigger-token
Tento token lze okamžitě přidat do obecné konfigurace proměnných pro skupinu projektů.
Přejděte do skupiny -> Nastavení -> CI / CD -> Proměnné a přidejte proměnnouDEPLOY_TOKENse spouštěcím tokenem v hodnotě.
GitLab Runner
Tato část popisuje konfiguraci pro spouštění úloh při nasazení pomocí nativního (Specifického) a veřejného (Sdíleného) spouštěče.
Konkrétní běžec
Používám vlastní běžce, protože je to především pohodlné, rychlé, levné.
Pro běžce doporučuji Linux VDS s 1 CPU, 2 GB RAM, 20 GB HDD. Emisní cena ~ 3000₽ ročně.
Můj běžec
Pro běžec jsem vzal VDS 4 CPU, 4 GB RAM, 50 GB SSD. Stálo to ~11000 XNUMX₽ a nikdy jsem toho nelitoval.
Mám celkem 7 strojů. 5 na arubě a 2 na ihor.
Takže máme běžce. Nyní to nastavíme.
Přes SSH přejdeme na stroj a nainstalujeme java, git, maven, gnupg2.
Instalace gitlab runner
- Vytvořte novou skupinu
runnersudo groupadd runner - Vytvořte adresář pro mezipaměť maven a přidělte práva skupině
runner
Tento krok můžete přeskočit, pokud neplánujete běžet více běžců na stejném stroji.mkdir -p /usr/cache/.m2/repository chown -R :runner /usr/cache chmod -R 770 /usr/cache - Vytvořte uživatele
gitlab-deployera přidat do skupinyrunneruseradd -m -d /home/gitlab-deployer gitlab-deployer usermod -a -G runner gitlab-deployer - Přidat do souboru
/etc/ssh/sshd_configdalší řádekAllowUsers root@* [email protected] - Restartujte
sshdsystemctl restart sshd - Nastavte heslo pro uživatele
gitlab-deployer(může to být jednoduché, protože pro localhost existuje omezení)passwd gitlab-deployer - Nainstalujte 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 - Přejděte na gitlab.com -> deploy-project -> Settings -> CI/CD -> Runners -> Specific Runners a zkopírujte registrační token
Obrazovka
- Registrace běžce
gitlab-runner register --config /etc/gitlab-runner/gitlab-deployer-config.toml
Proces
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!- Zkontrolujte, zda je běžec registrován. Přejděte na gitlab.com -> deploy-project -> Settings -> CI/CD -> Runners -> Specific Runners -> Runners aktivované pro tento projekt
Obrazovka
- Přidat odděleně služba
/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 - Spouštíme službu.
systemctl enable gitlab-deployer.service systemctl start gitlab-deployer.service systemctl status gitlab-deployer.service - Zkontrolujte, zda běžec běží.
příklad
Generování klíčů GPG
-
Ze stejného stroje jdeme přes ssh pod uživatelem
gitlab-deployer(to je důležité pro generování klíče GPG)ssh [email protected] -
Vygenerujeme klíč zodpovězením otázek. Použil jsem své jméno a e-mail.
Nezapomeňte zadat heslo pro klíč. Artefakty budou podepsány tímto klíčem.gpg --gen-key -
Zkontrolujte
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 -
Nahrání našeho veřejného klíče na server klíčů
gpg --keyserver keys.gnupg.net --send-key 00000000 gpg: sending key 00000000 to hkp server keys.gnupg.net
Nastavení Maven
- Jdeme pod uživatele
gitlab-deployersu gitlab-deployer - Vytvořte adresář maven Sklad a odkaz na cache (nenechte se mýlit)
Tento krok lze přeskočit, pokud neplánujete běžet několik běžců na stejném stroji.mkdir -p ~/.m2/repository ln -s /usr/cache/.m2/repository /home/gitlab-deployer/.m2/repository - Vytvořte hlavní klíč
mvn --encrypt-master-password password {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Vytvořte soubor ~/.m2/settings-security.xml
<settingsSecurity> <master>{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}</master> </settingsSecurity> - Šifrování hesla z účtu Sonatype
mvn --encrypt-password SONATYPE_PASSWORD {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J} - Vytvořte soubor ~/.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>
kde,
GPG_SECRET_KEY_PASSPHRASE – heslo klíče GPG
SONATYPE_USERNAME - přihlášení k účtu sonatype
Tím je nastavení běžce dokončeno, můžete pokračovat do sekce
Sdílený běžec
Generování klíčů GPG
-
Nejprve si musíte vytvořit GPG klíč. Chcete-li to provést, nainstalujte gnupg.
yum install -y gnupg -
Vygenerujeme klíč zodpovězením otázek. Použil jsem své jméno a e-mail. Nezapomeňte zadat heslo pro klíč.
gpg --gen-key -
Získejte klíčové informace
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] -
Nahrání našeho veřejného klíče na server klíčů
gpg --keyserver keys.gnupg.net --send-key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 gpg: sending key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 to hkp server keys.gnupg.net -
Získání soukromého klíče
gpg --export-secret-keys --armor 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 -----BEGIN PGP PRIVATE KEY BLOCK----- lQWGBFzAqp8BDADN41CPwJ/gQwiKEbyA902DKw/WSB1AvZQvV/ZFV77xGeG4K7k5 ... =2Wd2 -----END PGP PRIVATE KEY BLOCK----- -
Přejděte do nastavení projektu -> Nastavení -> CI / CD -> Proměnné a uložte soukromý klíč do proměnné
GPG_SECRET_KEY
Nastavení Maven
- Vytvořte hlavní klíč
mvn --encrypt-master-password password {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Přejděte do nastavení projektu -> Nastavení -> CI / CD -> Proměnné a uložte do proměnné
SETTINGS_SECURITY_XMLnásledující řádky:<settingsSecurity> <master>{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}</master> </settingsSecurity> - Šifrování hesla z účtu Sonatype
mvn --encrypt-password SONATYPE_PASSWORD {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J} - Přejděte do nastavení projektu -> Nastavení -> CI / CD -> Proměnné a uložte do proměnné
SETTINGS_XMLnásledující řádky:<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>
kde,
GPG_SECRET_KEY_PASSPHRASE – heslo klíče GPG
SONATYPE_USERNAME - přihlášení k účtu sonatype
Nasadit obrázek dockeru
-
Vytváříme poměrně jednoduchý Dockerfile pro spouštění úloh při nasazení s požadovanou verzí Javy. Níže je uveden příklad pro alpské.
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/ -
Stavba kontejneru pro váš projekt
docker build -t registry.gitlab.com/group/deploy . -
Ověříme a načteme kontejner do registru.
docker login -u USER -p PASSWORD registry.gitlab.com docker push registry.gitlab.com/group/deploy
GitLab CI
Nasadit projekt
Přidejte soubor .gitlab-ci.yml do kořenového adresáře projektu nasazení
Skript představuje dvě vzájemně se vylučující úlohy nasazení. Konkrétní běžec nebo sdílený běžec.
.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 projekt
V java projektech, které mají být nahrány do veřejných úložišť, musíte přidat 2 kroky ke stažení verzí Release a 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}V tomto řešení jsem šel trochu dále a rozhodl jsem se použít jednu CI šablonu pro java projekty.
Další podrobnosti
Vytvořil jsem samostatný projekt do kterého umístil šablonu CI pro java projekty .
obyčejný.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
Výsledkem je, že v samotných java projektech vypadá .gitlab-ci.yml velmi kompaktně a není mnohomluvný
.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
konfigurace pom.xml
Toto téma je popsáno velmi podrobně. в , takže popíšu některé nuance používání pluginů. Také popíšu, jak snadno a přirozeně můžete používat nexus-staging-maven-pluginpokud nechcete nebo nemůžete použít org.sonatype.oss:oss-parent jako rodiče pro váš projekt.
maven-install-plugin
Nainstaluje moduly do místního úložiště.
Velmi užitečné pro lokální ověření řešení v jiných projektech, stejně jako kontrolní součet.
<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>
plugin maven-javadoc
Generování javadoc pro projekt.
<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>Pokud máte modul, který neobsahuje java (například pouze zdroje)
Nebo v zásadě nechcete generovat javadoc, pak vám pomůže 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
<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
Konfigurace:
<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>Pokud máte projekt s více moduly a nepotřebujete nahrát konkrétní modul do úložiště, musíte přidat do pom.xml tohoto modulu nexus-staging-maven-plugin s vlajkou skipNexusStagingDeployMojo
<build>
<plugins>
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<configuration>
<skipNexusStagingDeployMojo>true</skipNexusStagingDeployMojo>
</configuration>
</plugin>
</plugins>
</build>Po nahrání snímku/vydání jsou dostupné verze v
<repositories>
<repository>
<id>SonatypeNexus</id>
<url>https://oss.sonatype.org/content/groups/staging/</url>
<!-- Не надо указывать флаги snapshot/release для репозитория -->
</repository>
</repositories>Další plusy
- Velmi bohatý seznam cílů pro práci s úložištěm nexus (
mvn help:describe -Dplugin=org.sonatype.plugins:nexus-staging-maven-plugin). - Automatická kontrola stažení pro stažení v maven central
Výsledek
Publikování verze SNAPSHOT
Při sestavování projektu je možné ručně spustit úlohu pro stažení verze SNAPSHOT do nexusu
Po spuštění této úlohy se spustí odpovídající úloha v projektu nasazení ().
oříznutý protokol
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] ------------------------------------------------------------------------V důsledku toho se načte verze pro nexus .
Všechny verze snímků lze odstranit z úložiště na webu pod vaším účtem.
Zveřejnění vydané verze
Když je značka nastavena, příslušná úloha v projektu nasazení se automaticky spustí a nahraje verzi vydání do zařízení nexus ().
Nejlepší na tom je, že blízké uvolnění se automaticky spustí v nexusu.
[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] ------------------------------------------------------------------------A pokud se něco pokazilo, úkol selže
[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] ------------------------------------------------------------------------Ve výsledku nám zbývá jediná možnost. Nebo tuto verzi smažte nebo publikujte.
Po vydání, po nějaké době, budou artefakty in
mimo téma
Bylo pro mě zjevením, že maven indexuje další veřejná úložiště.
Musel jsem nahrát soubor robots.txt, protože indexoval můj starý repozitář.
Závěr
Co máme
- Samostatný projekt nasazení, ve kterém můžete implementovat několik úloh CI pro nahrávání artefaktů do veřejných úložišť pro různé vývojové jazyky.
- Projekt nasazení je izolován od vnějšího rušení a mohou jej upravovat pouze uživatelé s rolemi Vlastník a Správce.
- Samostatný Specific Runner s „horkou“ mezipamětí pro spouštění pouze úloh nasazení.
- Publikování snímků/verzí vydání ve veřejném úložišti.
- Automatická kontrola připravenosti vydané verze k publikaci v maven central.
- Ochrana proti automatickému zveřejnění „raw“ verzí v maven central.
- Vytvářejte a publikujte verze snímků „na kliknutí“.
- Jediný repozitář pro získání verzí snímků/vydání.
- Obecný kanál pro vytváření / testování / publikování projektu Java.
Nastavení GitLab CI není tak složité téma, jak se na první pohled zdá. Stačí párkrát zřídit CI na klíč a teď v této věci zdaleka nejste amatér. Dokumentace GitLab je navíc velmi nadbytečná. Nebojte se udělat první krok. Cesta se objeví pod kroky toho, kdo jde (nepamatuji si, kdo to řekl :)
Budu rád za zpětnou vazbu.
V příštím článku vám ukážu, jak nastavit GitLab CI, aby spouštělo úlohy integračního testu konkurenceschopně (spouštění testovacích služeb s docker-compose), pokud máte pouze jeden shell runner.
Zdroj: www.habr.com