ProHoster > Blog > Stjórnsýsla > Að setja upp GitLab CI til að hlaða upp Java verkefni á Maven Central
Að setja upp GitLab CI til að hlaða upp Java verkefni á Maven Central
Þessi grein er ætluð Java forriturum sem þurfa að birta vörur sínar fljótt í sonatype og/eða maven miðlægar geymslur með GitLab. Í þessari grein mun ég tala um að setja upp gitlab-runner, gitlab-ci og maven-plugin til að leysa þetta vandamál.
Forkröfur:
Örugg geymsla mvn og GPG lykla.
Örugg framkvæmd opinberra CI verkefna.
Hleður upp gripum (útgáfu/skynmynd) í opinberar geymslur.
Sjálfvirk athugun á útgáfuútgáfum til birtingar í Maven Central.
Almenn lausn til að hlaða upp gripum í geymslu fyrir mörg verkefni.
Ítarlegri lýsingu á vélbúnaðinum til að birta gripi til Maven Central í gegnum Sonatype OSS geymsluhýsingarþjónustuna er þegar lýst í Þessi grein notandi Googolplex, svo ég mun vísa í þessa grein á réttum stöðum.
Forskráning kl Sónagerð JIRA og byrjaðu á miða til að opna geymsluna (fyrir frekari upplýsingar, lestu kaflann Búðu til Sonatype JIRA miða). Eftir að geymslan hefur verið opnuð verður JIRA innskráning/lykilorð parið (hér eftir nefnt Sonatype reikningurinn) notað til að hlaða upp gripum í Sonatype tengslin.
Ef þú ert að nota Linux stjórnborðið til að búa til GPG lykil (gnupg/gnupg2), þá þarftu að setja upp RNG-verkfæri að búa til óreiðu. Annars getur lyklagerð tekið mjög langan tíma.
Fyrst af öllu þarftu að búa til og stilla verkefni þar sem leiðslan verður geymd til að dreifa gripum. Ég kallaði verkefnið mitt einfaldlega og óbrotið - dreifa
Eftir að hafa búið til geymsluna þarftu að takmarka aðgang til að breyta geymslunni.
Farðu í verkefnið -> Stillingar -> Geymsla -> Vernduð útibú. Við eyðum öllum reglum og bætum við einni reglu með Wildcard * með réttinum til að ýta og sameina aðeins fyrir notendur með viðhaldshlutverkið. Þessi regla mun virka fyrir alla notendur bæði þessa verkefnis og hópsins sem þetta verkefni tilheyrir.
Ef það eru nokkrir umsjónarmenn, þá væri besta lausnin að takmarka aðgang að verkefninu í grundvallaratriðum.
Farðu í verkefnið -> Stillingar -> Almennt -> Sýnileiki, eiginleikar verkefnisins, heimildir og stilltu Sýnileika verkefnis á Einka.
Ég er með verkefni í almennum aðgangi, þar sem ég nota minn eigin GitLab Runner og aðeins ég hef aðgang til að breyta geymslunni. Jæja, reyndar er það ekki í mínum hagsmunum að sýna einkaupplýsingar í opinberum leiðsluskrám.
Herða reglur um breytingu á geymslunni
Farðu í verkefnið -> Stillingar -> Geymsla -> Push Rules og stilltu fánana Committer limitation, Athugaðu hvort höfundur er GitLab notandi. Ég mæli líka með stillingu skuldbinda sig til að skrifa undir, og stilltu Reject unsigned commit flagið.
Næst þarftu að stilla kveikju til að keyra verkefni
Farðu í verkefni -> Stillingar -> CI / CD -> Pipeline triggers og búðu til nýtt trigger-tákn
Þessum tákni er strax hægt að bæta við almenna stillingu breyta fyrir hóp verkefna.
Farðu í hópinn -> Stillingar -> CI / CD -> Breytur og bættu við breytu DEPLOY_TOKEN með trigger-token í gildinu.
Þessi hluti lýsir uppsetningunni fyrir að keyra verkefni við uppsetningu með því að nota innfædda (sérstaka) og opinbera (samnýttu) hlauparann.
Sérstakur hlaupari
Ég nota mína eigin hlaupara, því fyrst og fremst er það þægilegt, hratt, ódýrt.
Fyrir hlaupara mæli ég með Linux VDS með 1 CPU, 2 GB vinnsluminni, 20 GB HDD. Útgáfuverð ~3000 ₽ á ári.
Hlauparinn minn
Fyrir hlauparann tók ég VDS 4 CPU, 4 GB vinnsluminni, 50 GB SSD. Það kostaði ~11000₽ og sá aldrei eftir því.
Ég á alls 7 vélar. 5 á Aruba og 2 á ihor.
Svo erum við með hlaupara. Nú munum við setja það upp.
Við förum í vélina í gegnum SSH og setjum upp java, git, maven, gnupg2.
Búðu til möppu fyrir maven skyndiminni og úthlutaðu hópréttindum runner
Þú getur sleppt þessu skrefi ef þú ætlar ekki að keyra marga hlaupara á sömu vélinni.
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!
Athugaðu hvort hlauparinn sé skráður. Farðu á gitlab.com -> deploy-project -> Stillingar -> CI/CD -> Hlauparar -> Sérstakir hlauparar -> Hlauparar virkjaðir fyrir þetta verkefni
Skjár
Bæta við aðskilin þjónustu /etc/systemd/system/gitlab-deployer.service
Við búum til lykil með því að svara spurningum. Ég notaði mitt eigið nafn og netfang.
Vertu viss um að tilgreina lykilorð fyrir lykilinn. Munir verða undirritaðir með þessum lykli.
gpg --gen-key
Athuga
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
Hleður upp almenningslyklinum okkar á lyklaþjóninn
gpg --keyserver keys.gnupg.net --send-key 00000000
gpg: sending key 00000000 to hkp server keys.gnupg.net
Búðu til maven möppu geymsla og tengja við skyndiminni (ekki gera mistök)
Þetta skref er hægt að sleppa ef þú ætlar ekki að keyra nokkra hlaupara á sömu vélinni.
Bættu skránni .gitlab-ci.yml við rót dreifingarverkefnisins
Handritið sýnir tvö dreifingarverkefni sem útiloka hvor aðra. Sérstakur hlaupari eða sameiginlegur hlaupari í sömu röð.
.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
<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>
Ef þú ert með einingu sem inniheldur ekki Java (til dæmis aðeins tilföng)
Eða þú vilt ekki búa til javadoc í grundvallaratriðum, þá til að hjálpa maven-jar-plugin
Ef þú ert með verkefni með mörgum einingum og þú þarft ekki að hlaða upp ákveðinni einingu í geymsluna, þá þarftu að bæta við pom.xml þessarar einingar nexus-staging-maven-plugin með fána skipNexusStagingDeployMojo
Eftir að hafa hlaðið upp skyndimynd/útgáfu eru útgáfur fáanlegar í sviðsetningargeymslur
<repositories>
<repository>
<id>SonatypeNexus</id>
<url>https://oss.sonatype.org/content/groups/staging/</url>
<!-- Не надо указывать флаги snapshot/release для репозитория -->
</repository>
</repositories>
Fleiri plúsar
Mjög ríkur listi yfir markmið til að vinna með nexus geymsluna (mvn help:describe -Dplugin=org.sonatype.plugins:nexus-staging-maven-plugin).
Sjálfvirk losunarathugun á niðurhalshæfni í maven central
Þegar merkið er stillt er samsvarandi verkefni í dreifingarverkefninu sjálfkrafa ræst til að hlaða upp útgáfuútgáfunni á nexus (Dæmi).
Það besta er að lokaútgáfa fer sjálfkrafa af stað í 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] ------------------------------------------------------------------------
Og ef eitthvað fór úrskeiðis, þá mun verkefnið mistakast
[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] ------------------------------------------------------------------------
Þar af leiðandi stöndum við eftir með aðeins eitt val. Eða eyða þessari útgáfu eða birta.
Eftir útgáfuna, eftir nokkurn tíma, verða gripirnir komnir inn
utan umræðuefnis
Það var mér opinberun að Maven verðtryggir aðrar opinberar geymslur.
Ég þurfti að hlaða upp robots.txt vegna þess að það skráði gömlu geymsluna mína.
Sérstakt dreifingarverkefni þar sem þú getur innleitt nokkur CI verkefni til að hlaða upp gripum í opinberar geymslur fyrir ýmis þróunartungumál.
Dreifingarverkefnið er einangrað frá utanaðkomandi truflunum og einungis er hægt að breyta því af notendum með hlutverkin Owner og Maintainer.
Sérstakur hlaupari með „heitu“ skyndiminni til að keyra aðeins dreifingarverkefni.
Birting skyndimynda/útgáfuútgáfu í opinberri geymslu.
Sjálfvirk athugun á útgáfuútgáfunni til að vera reiðubúin til birtingar í Maven Central.
Vörn gegn sjálfvirkri birtingu á „hráum“ útgáfum í Maven Central.
Byggja og birta skyndimyndaútgáfur „með smelli“.
Ein geymsla til að fá skyndimynd/útgáfur.
Almenn leiðsla til að byggja / prófa / gefa út java verkefni.
Uppsetning GitLab CI er ekki eins flókið efni og það virðist við fyrstu sýn. Það er nóg að setja CI upp á turnkey grunni nokkrum sinnum, og nú ertu langt frá því að vera áhugamaður í þessu máli. Þar að auki eru GitLab skjöl mjög óþarfi. Ekki vera hræddur við að taka fyrsta skrefið. Vegurinn birtist undir tröppum þess sem gengur (ég man ekki hver sagði það :)
Ég mun vera fegin að fá endurgjöf.
Í næstu grein mun ég sýna þér hvernig á að setja upp GitLab CI til að keyra samþættingarprófunarverkefni samkeppnishæft (að keyra prófunarþjónustu með docker-compose) ef þú ert aðeins með einn skelhlaupara.