Ez a cikk java fejlesztőknek készült, akiknek szükségük van arra, hogy gyorsan publikálják termékeiket a sonatype és/vagy a maven central tárolóiban GitLab használatával. Ebben a cikkben bemutatom a gitlab-runner, gitlab-ci és a maven-plugin beállítását a feladat megoldására.
Előfeltételek:
- A mvn és GPG kulcsok biztonságos tárolása.
- A nyilvános CI feladatok biztonságos végrehajtása.
- Artefaktumok (release/snapshot) feltöltése nyilvános tárolókba.
- Automatikus ellenőrzés a release verziók publikálásához maven central-ba.
- Általános megoldás az artefaktumok tárolóba történő feltöltésére több projekthez.
- Egyszerűség és használhatóság.
Tartalom
Általános információ
- A Maven Central-ba történő artefaktum publikálás mechanizmusának részletes leírása már megtalálható a felhasználó által , ezért a szükséges helyeken hivatkozni fogok erre a cikkre.
- Először is regisztráljunk a oldalon, és nyissunk egy jegyet a tároló megnyitására (részletesebben olvasható a ). A tároló megnyitása után a JIRA felhasználónevünket/jelszavunkat (a továbbiakban Sonatype fiók) fogjuk használni az artefaktumok Sonatype nexus-ba történő feltöltéséhez.
- A GPG kulcs generálás folyamatát elég szárazon írják le. Részletesebben lásd a
- Ha Linux konzolt használsz a GPG kulcs generálásához (gnupg/gnupg2), akkor telepítened kell a -t az entropia generálásához. Ellenkező esetben a kulcs generálása nagyon hosszú ideig tarthat.
- Nyilvános tárolók GPG kulcsokhoz Beállítva a deploy-projektet a GitLab-ban
Először is létre kell hozni és beállítani egy projektet, amelyben a pipeline tárolni fogja az artefaktumok telepítését. Az én projektemet egyszerűen neveztem el —
- A tároló létrehozása után korlátozni kell a tároló módosításának hozzáférését.
- Lépjünk a projektre -> Beállítások -> Tároló -> Védett ágak. Töröljük a meglévő szabályokat, és adjunk hozzá egyetlen szabályt Wildcard * joggal a push és merge engedélyezésére csak a Fenntartók szerepkörrel rendelkező felhasználók számára. Ez a szabály minden felhasználóra vonatkozik, akár a projekt része, akár az a csoport, amelybe a projekt tartozik.
Lépjünk a projekthez -> Beállítások -> Repó -> Védett ágak. Töröljük az összes szabályt és hozzunk létre egyetlen szabályt Wildcard * használatával, push és merge joggal csak a Maintainers szerepkörű felhasználók számára. Ez a szabály minden felhasználóra vonatkozik, beleértve a projekt felhasználóit és a csoportot, amelybe a projekt tartozik.
- Ha több karbantartó is van, akkor a legjobb megoldás az, ha alapból korlátozzuk a hozzáférést a projekthez.
Lépjünk a projekthez -> Beállítások -> Általános -> Láthatóság, projektfunkciók, engedélyek, és állítsuk be a Projekt láthatóságot a következő értékre Private.
A projektet nyilvános hozzáférésűvé tettem, mivel saját GitLab Runner-t használok és csak nekem van jogom a repository módosítására. S nem érdekel, hogy privát információk jelenjenek meg nyilvános pipeline logokban. - A repository módosítási szabályainak szigorítása
Lépjünk a projekthez -> Beállítások -> Repository -> Push szabályok és állítsuk be a Committer restriction és a GitLab felhasználó-e a szerző ellenőrzését. Azt is javaslom, hogy konfiguráljuk a , és állítsuk be a Reject unsigned commits jelölőt. - Ezután egy trigger beállítása szükséges a feladatok elindításához
Lépjünk a projekthez -> Beállítások -> CI / CD -> Pipeline triggerek és hozzunk létre egy új trigger-token-t
Ezt a tokent azonnal hozzáadhatjuk a projektek csoportjának általános konfigurációs változóihoz.
Lépjünk a csoporthoz -> Beállítások -> CI / CD -> Változók és adjuk hozzá a változótDEPLOY_TOKENtrigger-token értékkel.
GitLab Runner
Ebben a részben a feladatok deploy-ra indításához szükséges konfigurációt írja le, saját (Specific) és nyilvános (Shared) runner használatával.
Specifikus Runner
Saját runnereket használok, mert ez először is kényelmes, gyors és olcsó.
A runnerhez javaslom a linuxos VDS-t 1 CPU-val, 2 GB RAM-mal és 20 GB HDD-vel. Az ár körülbelül ~3000₽ évente.
Az én runnerem
A runneremhez VDS-t választottam 4 CPU-val, 4 GB RAM-mal és 50 GB SSD-vel. Kb. ~11000₽-ba került, és azóta sem bántam meg.
Összesen 7 gépem van. 5 az arubán és 2 az ihoron.
Tehát, van egy runnerünk. Most konfigurálni fogjuk.
Belépünk a gépre SSH-n keresztül, és telepítjük a java-t, git-et, maven-t, gnupg2-t.
GitLab runner telepítése
- Új csoport létrehozása
runnersudo groupadd runner - Létrehozunk egy könyvtárat a maven cache-nek és hozzárendeljük a csoport jogosultságait
runner
Ezt a lépést kihagyhatod, ha nem tervezel több runnert futtatni egy gépen.mkdir -p /usr/cache/.m2/repository chown -R :runner /usr/cache chmod -R 770 /usr/cache - Felhasználó létrehozása
gitlab-deployerés hozzáadjuk a csoporthozrunneruseradd -m -d /home/gitlab-deployer gitlab-deployer usermod -a -G runner gitlab-deployer - Hozzáadjuk a fájlhoz
/etc/ssh/sshd_configa következő sortAllowUsers root@* gitlab-deployer@127.0.0.1 - Újraindítjuk
sshdsystemctl restart sshd - Jelszót állítunk be a felhasználó számára
gitlab-deployer(lehet egyszerű, mivel localhost-ra határozott korlátozás van)passwd gitlab-deployer - GitLab Runner telepítése (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 - Lépjünk a gitlab.com oldalra -> deploy-projekt -> Beállítások -> CI/CD -> Runners -> Specifikus Runners és másoljuk ki a registration tokent
Kép
- Regisztráljuk a futót
gitlab-runner register --config /etc/gitlab-runner/gitlab-deployer-config.toml
Folyamat
Futási platform arch=amd64 os=linux pid=17594 revision=3001a600 version=11.10.0
Rendszermódban fut.
Kérem, adja meg a gitlab-ci koordinátor URL-jét (pl. https://gitlab.com/):
https://gitlab.com/
Kérem, adja meg a gitlab-ci tokent erre a futóra:
REGISTRATION_TOKEN
Kérem, adja meg a gitlab-ci leírást erre a futóra:
[ih1174328.vds.myihor.ru]: Deploy Runner
Kérem, adja meg a gitlab-ci címkéket erre a futóra (vesszővel elválasztva):
deploy
Futó regisztrálása... sikerült futó=ZvKdjJhx
Kérem, adja meg az executort: docker-ssh, parallels, virtualbox, docker-ssh+machine, kubernetes, docker, ssh, docker+machine, shell:
shell
Futó sikeresen regisztrálva. Nyugodtan indítsa el, de ha már fut, a konfiguráció automatikusan újratöltődik!- Ellenőrizzük, hogy a futó regisztrálva van. Lépjünk a gitlab.com oldalra -> deploy-projekt -> Beállítások -> CI/CD -> Runners -> Specifikus Runners -> Runners aktiválva ehhez a projekthez
Kép
- Hozzáadjuk külön szolgáltatás
/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 - Indítsuk el a szolgáltatást.
systemctl enable gitlab-deployer.service systemctl start gitlab-deployer.service systemctl status gitlab-deployer.service - Ellenőrizzük, hogy a futó elindult-e.
támadásra
GPG kulcsok generálása
- Ugyanerről a gépről lépjünk be ssh-val a felhasználóval
gitlab-deployer(ez fontos a GPG kulcs generálásához)ssh gitlab-deployer@127.0.0.1 - Generáljuk a kulcsot a kérdésekre válaszolva. Én a saját nevemet és email címemet használtam.
Kötelező megadni a kulcs jelszavát. Ezzel a kulccsal fogják aláírni az artefaktumokat.gpg --gen-key - Ellenőrzés
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 - Feltöltjük nyilvános kulcsunkat a kulcsszerverre
gpg --keyserver keys.gnupg.net --send-key 00000000 gpg: sending key 00000000 to hkp server keys.gnupg.net
Maven beállítása
- Lépjünk be a felhasználóval
gitlab-deployersu gitlab-deployer - Hozzunk létre egy maven könyvtárat repository és linkeljük a cache-hez (ne tévedjenek el)
Ezt a lépést kihagyhatjuk, ha nem tervezzük több futó indítását ugyanazon a gépen.mkdir -p ~/.m2/repository ln -s /usr/cache/.m2/repository /home/gitlab-deployer/.m2/repository - Hozzuk létre a mester kulcsot
mvn --encrypt-master-password password {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Hozzuk létre a fájlt ~/.m2/settings-security.xml
{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Titkosítjuk a Sonatype fiók jelszavát
mvn --encrypt-password SONATYPE_PASSWORD {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J} - Hozzunk létre egy fájlt ~/.m2/settings.xml
env true GPG_SECRET_KEY_PASSPHRASE sonatype SONATYPE_USERNAME {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}
ahol,
GPG_SECRET_KEY_PASSPHRASE — jelszó a GPG kulcshoz
SONATYPE_USERNAME — sonatype fiók név
Ezzel befejeződött a futtató beállítása, át lehet térni a szakaszra
Megosztott Runner
GPG kulcsok generálása
- Elsődlegesen létre kell hozni a GPG kulcsot. Ehhez telepítsük a gnupg-t.
yum install -y gnupg - Generáljuk a kulcsot, válaszolva a kérdésekre. Én a saját nevemet és e-mailem használtam. Ne felejtsük el megadni a kulcs jelszavát.
gpg --gen-key - Kinyomtatjuk a kulcs információit
gpg --list-keys -a pub rsa3072 2019-04-24 [SC] [expires: 2021-04-23] 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 uid [ultimate] tttemp sub rsa3072 2019-04-24 [E] [expires: none] - Feltöltjük nyilvános kulcsunkat a kulcsszerverre
gpg --keyserver keys.gnupg.net --send-key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 gpg: sending key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 to hkp server keys.gnupg.net - Megkapjuk a privát kulcsot
gpg --export-secret-keys --armor 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 -----BEGIN PGP PRIVATE KEY BLOCK----- lQWGBFzAqp8BDADN41CPwJ/gQwiKEbyA902DKw/WSB1AvZQvV/ZFV77xGeG4K7k5 ... =2Wd2 -----END PGP PRIVATE KEY BLOCK----- - Átmegyünk a projekt beállításaihoz -> Beállítások -> CI / CD -> Változók és elmentjük a privát kulcsot a változóba
GPG_SECRET_KEY
Maven beállítása
- Hozzuk létre a mester kulcsot
mvn --encrypt-master-password password {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Átmegyünk a projekt beállításaihoz -> Beállítások -> CI / CD -> Változók és elmentjük a változóba
SETTINGS_SECURITY_XMLa következő sorokat:{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Titkosítjuk a Sonatype fiók jelszavát
mvn --encrypt-password SONATYPE_PASSWORD {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J} - Átmegyünk a projekt beállításaihoz -> Beállítások -> CI / CD -> Változók és elmentjük a változóba
SETTINGS_XMLa következő sorokat:env true GPG_SECRET_KEY_PASSPHRASE sonatype sonatype_username {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}
ahol,
GPG_SECRET_KEY_PASSPHRASE — jelszó a GPG kulcshoz
SONATYPE_USERNAME — sonatype fiók név
Docker kép telepítése
- Készítünk egy viszonylag egyszerű Dockerfile-t, hogy feladatokat futtathassunk a szükséges Java verzióval. Az alábbi példa az alpine számára készült.
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/ - Összeállítjuk a tárolót a projektedhez
docker build -t registry.gitlab.com/group/deploy . - Hitelesítjük magunkat és feltöltjük a tárolót a registry-be.
docker login -u USER -p PASSWORD registry.gitlab.com docker push registry.gitlab.com/group/deploy
GitLab CI
Projekt telepítése
A deploy projekt gyökérébe hozzáadjuk a .gitlab-ci.yml fájlt
A szkriptben két, egymást kizáró feladat szerepel a telepítéshez. Specific Runner vagy Shared Runner a megfelelően.
.gitlab-ci.yml
stages:
- deploy
Specific Runner:
extends: .java_deploy_template
# A feladat az ön shell futtatóján fog futni
tags:
- deploy
Shared Runner:
extends: .java_deploy_template
# A feladat a nyilvános docker futtatón fog futni
tags:
- docker
# Kép a GitLab Runner -> Shared Runner -> Docker részben
image: registry.gitlab.com/group/deploy-project:latest
before_script:
# GPG kulcs importálása
- printf "${GPG_SECRET_KEY}" | gpg --batch --import
# Maven konfiguráció mentése
- printf "${SETTINGS_SECURITY_XML}" > ~/.m2/settings-security.xml
- printf "${SETTINGS_XML}" > ~/.m2/settings.xml
.java_deploy_template:
stage: deploy
# A feladat akkor fog működni, ha a DEPLOY változó java értéket kap
only:
variables:
- $DEPLOY == "java"
variables:
# a jelenlegi projekt klónozásának letiltása
GIT_STRATEGY: none
script:
# Lehetőséget biztosítunk a jelszó mentésére titkosítás nélkül
- git config --global credential.helper store
# Ideiglenes hitelesítők mentése gitlab-ci-token felhasználónak
# A token minden nyilvános gitlab.com projekthez és a csoport projektjeihez működik
- echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" >> ~/.git-credentials
# Teljesen kitakarítjuk az aktuális könyvtárat
- rm -rf .* *
# Klónozzuk a Sonatype Nexusba telepítendő projektet
- git clone ${DEPLOY_CI_REPOSITORY_URL} .
# Átkapcsolunk a szükséges commit-ra
- git checkout ${DEPLOY_CI_COMMIT_SHA} -f
# Ha bármely pom.xml tartalmazza az autoReleaseAfterClose paramétert, érvénytelenítjük a buildet.
# Máskülönben kockázatot jelent, hogy nyers artefaktumokat töltsünk fel a maven centralra
- >
for pom in $(find . -name pom.xml); do
if [[ $(grep -q autoReleaseAfterClose "$pom" && echo $?) == 0 ]]; then
echo "A(z) $pom fájl tiltott beállítást tartalmaz: <autoReleaseAfterClose>";
exit 1;
fi;
done
# Ha a DEPLOY_CI_COMMIT_TAG paraméter üres, akkor kötelezően SNAPSHOT verziót állítunk be
- >
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
# A feladat elindítása artefaktumok buildelésére és telepítésére
- mvn clean deploy -DskipTests=trueJava projekt
A nyilvános tárolókba feltöltésre szánt java projektekhez 2 lépést kell hozzáadni a Release és Snapshot verziók feltöltésére.
.gitlab-ci.yml
szakaszok:
- építés
- teszt
- ellenőrzés
- telepítés
Kiadás:
kiterjeszti: .trigger_deploy
# Csak címke szerint futtassa a feladatot.
csak:
- címkék
Snapshot:
kiterjeszti: .trigger_deploy
# A SNAPSHOT verzió publikálására fenntartott feladatot kézzel indítjuk el
amikor: kézi
# Ne indítsa el a feladatot, ha címke van beállítva.
kivéve:
- címkék
.trigger_deploy:
szakasz: telepítés
változók:
# Kikapcsolja a jelenlegi projekt másolását
GIT_STRATEGY: none
# A telepítési feladat trigger-linkje
URL: "https://gitlab.com/api/v4/projects//trigger/pipeline"
# A telepítési feladat változói
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:
# Nem használok cURL-t, mert a --fail --show-error zászlókkal
# nem adja vissza a válasz testét, ha a HTTP kód 400 vagy annál magasabb
- wget --content-on-error -qO- ${URL} --post-data ${POST_DATA}Ebben a megoldásban kicsit tovább mentem, és úgy döntöttem, hogy egy CI sablont használok a java projektekhez.
Részletesebben
Létrehoztam egy külön projektet amelyben elhelyeztem a CI sablont java projektekhez .
common.yml
szakaszok:
- építés
- teszt
- ellenőrzés
- telepítés
változók:
SONAR_ARGS: "
-Dsonar.gitlab.commit_sha=${CI_COMMIT_SHA}
-Dsonar.gitlab.ref_name=${CI_COMMIT_REF_NAME}
"
.build_java_project:
szakasz: építés
címkék:
- touchbit-shell
változók:
SKIP_TEST: "false"
script:
- mvn clean
- mvn package -DskipTests=${SKIP_TEST}
artifacts:
amikor: mindig
lejár: 30 nap
utak:
- "*\/target\/reports"
.build_sphinx_doc:
szakasz: építés
címkék:
- touchbit-shell
változók:
DOCKERFILE: .indirect\/docs\/Dockerfile
script:
- docker build --no-cache -t ${CI_PROJECT_NAME}\/doc -f ${DOCKERFILE} .
.junit_module_test_run:
szakasz: teszt
címkék:
- touchbit-shell
változók:
MODULE: ""
script:
- cd ${MODULE}
- mvn test
artifacts:
amikor: mindig
lejár: 30 nap
utak:
- "*\/target\/reports"
.junit_test_run:
szakasz: teszt
címkék:
- touchbit-shell
script:
- mvn test
artifacts:
amikor: mindig
lejár: 30 nap
utak:
- "*\/target\/reports"
.sonar_review:
szakasz: ellenőrzés
címkék:
- touchbit-shell
függőségek: []
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:
szakasz: telepítés
címkék:
- touchbit-shell
változók:
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:
kiterjeszti: .trigger_deploy
csak:
- címkék
.trigger_snapshot_deploy:
kiterjeszti: .trigger_deploy
amikor: kézi
kivéve:
- címkék
Ennek következtében a java projektek .gitlab-ci.yml fájlja meglehetősen tömör és lényegretörő.
.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_deploypom.xml konfigurálása
Ez a téma nagyon részletesen van leírva. be. , ezért bemutatok néhány plugin használatával kapcsolatos finomságot. Azt is megmutatom, milyen egyszerűen és könnyedén lehet használni. nexus-staging-maven-plugin, ha nem szeretnéd vagy nem tudod használni az org.sonatype.oss:oss-parent-t mint szülő projektet.
maven-install-plugin
Helyben telepíti a modulokat a lokális repóba.
Nagyon hasznos a megoldások helyi ellenőrzésére más projektekben, valamint a checksum ellenőrzésére is.
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
truemaven-javadoc-plugin
Javadoc generálása a projekthez.
org.apache.maven.plugins
maven-javadoc-plugin
jar
prepare-package
true
true
falseHa van egy modulod, amely nem tartalmaz java-t (például csak erőforrásokat),
vagy ha egyáltalán nem szeretnél javadoc-ot generálni, akkor itt a segítség. maven-jar-plugin
org.apache.maven.plugins
maven-jar-plugin
empty-javadoc-jar
generate-resources
jar
javadoc
${basedir}/javadocmaven-gpg-plugin
org.apache.maven.plugins
maven-gpg-plugin
sign-artifacts
deploy
signnexus-staging-maven-plugin
Konfiguráció:
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/Ha többmodulos projektje van, és nincs szüksége egy adott modul feltöltésére a tárolóba, akkor a modul pom.xml fájljába a következőt kell hozzáadnia: nexus-staging-maven-plugin zászlóval skipNexusStagingDeployMojo
org.sonatype.plugins
nexus-staging-maven-plugin
trueA snapshot/release verziók feltöltése után elérhetők a
<repositories>
<repository>
<id>SonatypeNexus<\/id>
<url>https:\/\/oss.sonatype.org\/content\/groups\/staging\/<\/url>
<!-- Ne állítsa be a snapshot\/release zászlókat a tárolóhoz -->
<\/repository>
<\/repositories>További előnyök
- Nagyon gazdag céllista a nexus tárolóval való munkához (
mvn help:describe -Dplugin=org.sonatype.plugins:nexus-staging-maven-plugin). - Automatikus ellenőrzés a kiadás maven centralba való feltöltésének lehetőségéről
Eredmény
SNAPSHOT verzió közzététele
A projekt építésekor lehetőség van a SNAPSHOT verzió nexusba történő feltöltési feladat kézi indítására
A feladat elindításakor aktiválódik a megfelelő feladat a deploy projektben ().
Levágott napló
A gitlab-runner 11.10.0 (3001a600) futása
a Deploy runner JSKWyxUw-on
Shell executor használata...
A(z) ih1174328.vds.myihor.ru-n fut...
Git tároló beállításának kihagyása
Git checkout kihagyása
Git almodul beállításának kihagyása
$ 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} .
Klónozás a 'shields4j'-ba...
$ git checkout ${DEPLOY_CI_COMMIT_SHA}
Figyelem: '850f86aa317194395c5387790da1350e437125a7' kicsomagolása.
"Detached HEAD" állapotban vagy. Körülnézhetsz, kísérleti
változtatásokat végezhetsz és azokat elkötheted, valamint
bármely elkötelezett változtatást elvethetsz ebben
az állapotban anélkül, hogy az bármely ágat befolyásolna, ha újra checkout-olsz.
Ha új ágat szeretnél létrehozni az elkötelezett változtatásaid megtartásához, akkor ezt
teheted (most vagy később) az -b kapcsoló használatával a checkout parancs újra történő végrehajtásakor. Példa:
git checkout -b új_ág_neve
A HEAD most a 850f86a... kihagyja a deploy-t test-core
$ for pom in $(find . -name pom.xml); do # többlépéses parancs összecsukva
$ if [[ "${DEPLOY_CI_COMMIT_TAG}" != "" ]]; then # többlépéses parancs összecsukva
[INFO] Projektek beolvasása...
[INFO] A build ellenőrzése összesen 4 modul van...
[INFO] Nexus Staging funkciók telepítése:
[INFO] ... összesen 4 végrehajtás a maven-deploy-plugin helyett nexus-staging-maven-plugin
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] Shields4J [pom]
[INFO] test-core [jar]
[INFO] Shields4J kliens [jar]
[INFO] TestNG listener [jar]
[INFO]
[INFO] -----------------------------
[INFO] A Shields4J 1.0.0 építése [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- versions-maven-plugin:2.5:set (default-cli) @ shields4j-parent ---
[INFO] Helyi aggregátor gyökér keresése...
[INFO] Helyi aggregálás gyökér: /home/gitlab-deployer/JSKWyxUw/0/TouchBIT/deploy/shields4j
[INFO] A változás feldolgozása org.touchbit.shields4j:shields4j-parent:1.0.0 -> 1.0.0-SNAPSHOT
[INFO] org.touchbit.shields4j:shields4j-parent feldolgozása
[INFO] A projekt frissítése org.touchbit.shields4j:shields4j-parent
[INFO] a verzió frissítése 1.0.0-ról 1.0.0-SNAPSHOT-ra
[INFO]
[INFO] org.touchbit.shields4j:client feldolgozása
[INFO] A szülő frissítése org.touchbit.shields4j:shields4j-parent
[INFO] a verzió frissítése 1.0.0-ról 1.0.0-SNAPSHOT-ra
[INFO] A függőség org.touchbit.shields4j:test-core frissítése
[INFO] a verzió frissítése 1.0.0-ról 1.0.0-SNAPSHOT-ra
[INFO]
[INFO] org.touchbit.shields4j:test-core feldolgozása
[INFO] A szülő frissítése org.touchbit.shields4j:shields4j-parent
[INFO] a verzió frissítése 1.0.0-ról 1.0.0-SNAPSHOT-ra
[INFO]
[INFO] org.touchbit.shields4j:testng feldolgozása
[INFO] A szülő frissítése org.touchbit.shields4j:shields4j-parent
[INFO] a verzió frissítése 1.0.0-ról 1.0.0-SNAPSHOT-ra
[INFO] A függőség org.touchbit.shields4j:client frissítése
[INFO] a verzió frissítése 1.0.0-ról 1.0.0-SNAPSHOT-ra
[INFO] A függőség org.touchbit.shields4j:test-core frissítése
[INFO] a verzió frissítése 1.0.0-ról 1.0.0-SNAPSHOT-ra
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor összefoglaló:
[INFO]
[INFO] Shields4J 1.0.0 .................................... SIKERES [ 0.992 s]
[INFO] test-core .......................................... KIHAGYVA
[INFO] Shields4J kliens ................................... KIHAGYVA
[INFO] TestNG listener 1.0.0 .............................. KIHAGYVA
[INFO] ------------------------------------------------------------------------
[INFO] ÉPÍTÉS SIKERES
[INFO] ------------------------------------------------------------------------
[INFO] Összes idő: 2.483 s
[INFO] Befejezve: 2019-04-21T02:40:42+03:00
[INFO] ------------------------------------------------------------------------
$ mvn clean deploy -DskipTests=${SKIP_TESTS}
[INFO] Projektek beolvasása...
[INFO] A build ellenőrzése összesen 4 modul van...
[INFO] Nexus Staging funkciók telepítése:
[INFO] ... összesen 4 végrehajtás a maven-deploy-plugin helyett nexus-staging-maven-plugin
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] Shields4J [pom]
[INFO] test-core [jar]
[INFO] Shields4J kliens [jar]
[INFO] TestNG listener [jar]
[INFO]
[INFO] -----------------------------
[INFO] A Shields4J 1.0.0-SNAPSHOT építése [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
...
TÖRÖLVE
...
[INFO] * Helyi összegyűjtött snapshot artefaktumok tömeges telepítése befejeződött.
[INFO] A távoli telepítés sikeresen befejeződött.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor összefoglaló:
[INFO]
[INFO] Shields4J 1.0.0-SNAPSHOT ........................... SIKERES [ 2.375 s]
[INFO] test-core .......................................... SIKERES [ 3.929 s]
[INFO] Shields4J kliens ................................... SIKERES [ 3.815 s]
[INFO] TestNG listener 1.0.0-SNAPSHOT ..................... SIKERES [ 36.134 s]
[INFO] ------------------------------------------------------------------------
[INFO] ÉPÍTÉS SIKERES
[INFO] ------------------------------------------------------------------------
[INFO] Összes idő: 47.629 s
[INFO] Befejezve: 2019-04-21T02:41:32+03:00
[INFO] ------------------------------------------------------------------------Ennek eredményeként a Nexus-ba a verzió került betöltésre .
Minden snapshot verzió törölhető a webhely tárolójából a saját fiókjával.
Release verzió publikálása
A címke telepítésekor automatikusan triggerálódik a megfelelő feladat a deploy projekten a kiadott verzió Nexus-ba történő betöltésére ().
A legjobb hír, hogy automatikusan életbe lép a kiadás lezárása a Nexus-ban.
[INFO] Távoli staging végrehajtása...
[INFO]
[INFO] * Távoli staging a staging profil ID "9043b43f77dcc9" alapján
[INFO] * Staging tároló létrehozva a "orgtouchbit-1037" ID-val.
[INFO] * Staging tároló a következő címen: https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1037
[INFO] * Helyileg tárolt artefaktumok feltöltése az org.touchbit profilhoz
[INFO] * A helyileg tárolt artefaktumok feltöltése befejeződött.
[INFO] * A staging tároló zárása a "orgtouchbit-1037" ID-val.
Várakozás a művelet befejezésére...
.........
[INFO] Távoli staging 1 tároló, sikeresen befejezve.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor összegzés:
[INFO]
[INFO] Shields4J 1.0.0 .................................... SIKERES [ 9.603 s]
[INFO] test-core .......................................... SIKERES [ 3.419 s]
[INFO] Shields4J kliens ................................... SIKERES [ 9.793 s]
[INFO] TestNG listener 1.0.0 .............................. SIKERES [01:23 p]
[INFO] ------------------------------------------------------------------------
[INFO] ÉPÍTÉS SIKERES
[INFO] ------------------------------------------------------------------------
[INFO] Összes idő: 01:47 p
[INFO] Befejezés időpontja: 2019-04-21T04:05:46+03:00
[INFO] ------------------------------------------------------------------------És ha valami nem úgy alakult, ahogy kellett volna, a feladat biztosan el fog bukni
[INFO] Távoli színpad végrehajtása...
[INFO]
[INFO] * Távoli színpad a "9043b43f77dcc9" színpadi profilba
[INFO] * Színpadi tároló létrehozva az "orgtouchbit-1038" azonosítóval.
[INFO] * Színpadi tároló elérhetősége: https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1038
[INFO] * Helyben színpadra állított artefaktumok feltöltése az org.touchbit profilba
[INFO] * A helyben színpadra állított artefaktumok feltöltése befejeződött.
[INFO] * Színpadi tároló zárása az "orgtouchbit-1038" azonosítóval.
Várakozás a művelet befejezésére...
.......
[ERROR] Szabályhiba a színpadi tároló "orgtouchbit-1039" zárása közben.
[ERROR]
[ERROR] Nexus Staging Szabályok Hibajelentés
[ERROR] ==================================
[ERROR]
[ERROR] "orgtouchbit-1039" tároló hibái
[ERROR] "signature-staging" szabály hibái
[ERROR] * Nincs nyilvános kulcs: A(z) (1f42b618d1cbe1b5) azonosítójú kulcs nem található a <a href=http://keys.gnupg.net:11371/>http://keys.gnupg.net:11371/</a> címen. Töltse fel nyilvános kulcsát, és próbálja újra a műveletet.
...
[ERROR] Helyi színpadi könyvtár takarítása a szabályhiba után a színpadi tárolók zárása közben: [orgtouchbit-1039]
[ERROR] * A kontextus törlése: 9043b43f77dcc9.properties
[ERROR] Távoli színpadi tárolók takarítása a szabályhiba után a színpadi tárolók zárása közben: [orgtouchbit-1039]
[ERROR] * A hibás színpadi tároló törlése az "orgtouchbit-1039" azonosítóval (Szabályhiba a színpadi tárolók zárásakor: [orgtouchbit-1039]).
[ERROR] A távoli színpad befejeződött egy hibával: Színpadiszabályok hibája!
[INFO] ------------------------------------------------------------------------
[INFO] Reaktor összegzés:
[INFO]
[INFO] Shields4J 1.0.0 .................................... SIKER [ 4.073 s]
[INFO] test-core .......................................... SIKER [ 2.788 s]
[INFO] Shields4J kliens ................................... SIKER [ 3.962 s]
[INFO] TestNG figyelő 1.0.0 .............................. HIBA [01:07 min]
[INFO] ------------------------------------------------------------------------
[INFO] ÉPÍTÉSI HIBA
[INFO] ------------------------------------------------------------------------Így egyetlen választási lehetőségünk maradt. Vagy töröljük ezt a verziót, vagy közzétesszük.
A kiadás után, egy idő elteltével az artefaktumok a következő helyre kerülnek:
offtop
Meghökkentem, hogy a maven más nyilvános tárolókat is indexál.
Fel kellett töltenem a robots.txt-t, mivel indexálta a régi tárolómat.
Zárás
Mit kapunk?
- Egy külön deploy-projekt, amelyben több CI feladatot valósíthatunk meg artefaktumok nyilvános tárolókba történő feltöltésére különböző fejlesztési nyelvekhez.
- A deploy-projekt elkülönítve van a külső beavatkozásoktól, és csak a Tulajdonos és Karbantartó szerepkörű felhasználók módosíthatják.
- Egy külön Specific Runner "meleg" cache-sel a deploy feladatok futtatására.
- Snapshot/release verziók közzététele a nyilvános tárolóban.
- Automatikus ellenőrzés a release verziók publikáláshoz való alkalmasságáról a maven centralban.
- Védelem a "nyers" verziók maven centralban való automatikus közzétételétől.
- Snapshot verziók összeállítása és közzététele "kattintással".
- Egységes tároló a snapshot/release verziók beszerzéséhez.
- Általános értekezlet a java projekt összeállításáról/teszteréséről/kiadásáról.
A GitLab CI beállítása nem olyan bonyolult téma, mint elsőre tűnik. Elég néhány alkalommal beállítani a CI-t "kulcsrakész" módon, és máris messze nem vagy kezdő a témában. Főleg, hogy a GitLab dokumentáció rendkívül részletes. Ne félj az első lépést megtenni. Az út akkor alakul ki, amikor lépéseket tesz valaki (nem emlékszem, ki mondta 🙂 ).
Örömmel várom a visszajelzéseket.
A következő cikkben arról fogok beszélni, hogyan lehet beállítani a GitLab CI-t a feladatok párhuzamos futtatására integrációs tesztekkel (a tesztelt szolgáltatások docker-compose segítségével történő indításával), ha csak egy shell futtató áll rendelkezésre.
Forrás: habr.com
