Dit artikel is bedoeld voor Java-ontwikkelaars die snel hun producten willen publiceren in de Sonatype- en/of Maven Central-repositories met behulp van GitLab. In dit artikel bespreek ik de configuratie van gitlab-runner, gitlab-ci en maven-plugin om deze taak uit te voeren.
Vereisten:
- Veilige opslag van mvn- en GPG-sleutels.
- Veilige uitvoering van openbare CI-taken.
- Uploaden van artefacten (release/snapshot) naar openbare repositories.
- Automatische controle van releaseversies voor publicatie in Maven Central.
- Algemene oplossing voor het uploaden van artefacten naar de repository voor meerdere projecten.
- Eenvoud en gebruiksgemak.
Inhoud
Algemene informatie
- Een gedetailleerde beschrijving van het mechanisme voor de publicatie van artefacten in Maven Central via Sonatype OSS Repository Hosting Service is al beschreven in de gebruiker , daarom zal ik op de nodige plaatsen naar dit artikel verwijzen.
- Registreren bij en een ticket aanmaken voor het openen van de repository (meer details lezen in de sectie ). Na het openen van de repository zal de combinatie van gebruikersnaam/wachtwoord van JIRA (verder de Sonatype-account) worden gebruikt voor het uploaden van artefacten naar Sonatype nexus.
- Daarna wordt het proces van het genereren van de GPG-sleutel vrij beknopt beschreven. Zie de sectie
- Als je de Linux-console gebruikt om de GPG-sleutel te genereren (gnupg/gnupg2), moet je installeren om entropie te genereren. Anders kan het genereren van de sleutel heel lang duren.
- Opslagdiensten openbare GPG-sleutels
Configuratie van het deploy-project in GitLab
- Ten eerste moet je een project aanmaken en configureren waarin de pipeline voor de implementatie van artefacten wordt opgeslagen. Mijn project heb ik eenvoudig en onopvallend genaamd ā
- Na het aanmaken van de repository moeten we de toegang tot het wijzigen van de repository beperken.
Ga naar het project -> Instellingen -> Repository -> Beschermde Takken. Verwijder alle regels en voeg Ć©Ć©n enkele regel met Wildcard * toe, met push- en merge-rechten alleen voor gebruikers met de rol van Maintainers. Deze regel zal van toepassing zijn voor alle gebruikers van dit project en de groep waarvan dit project deel uitmaakt.
- Als er meerdere maintainers zijn, is het beste om de toegang tot het project in het algemeen te beperken.
Ga naar het project -> Instellingen -> Algemeen -> Zichtbaarheid, projectfuncties, machtigingen en stel Project zichtbaarheid in op PrivƩ.
Mijn project is openbaar toegankelijk, omdat ik een eigen GitLab Runner gebruik en alleen ik rechten heb om de repository te wijzigen. Het is ook niet in mijn belang om privƩ-informatie in openbare pipeline-logboeken te laten zien. - Verstrengeling van regels voor repository-wijzigingen
Ga naar het project -> Instellingen -> Repository -> Push-regels en stel de vlaggen Committer-beperkingen, Controle of de auteur een GitLab-gebruiker is in. Ik raad ook aan om in te schakelen en de vlag Weiger niet-ondertekende commits in te stellen. - Daarna is het vereist om een trigger in te stellen voor het starten van taken
Ga naar het project -> Instellingen -> CI / CD -> Pipeline-triggers en maak een nieuwe trigger-token aan
Deze token kan onmiddellijk aan de algemene configuratie van variabelen voor de projectgroep worden toegevoegd.
Ga naar de groep -> Instellingen -> CI / CD -> Variabelen en voeg de variabeleDEPLOY_TOKENmet trigger-token als waarde toe.
GitLab Runner
In dit gedeelte wordt de configuratie beschreven voor het starten van taken voor deployment met behulp van een eigen (Specific) en openbare (Shared) runner.
Specifieke Runner
Ik gebruik eigen runners omdat dit in de eerste plaats handig, snel en goedkoop is.
Voor de runner raad ik een Linux VDS aan met 1 CPU, 2 GB RAM, 20 GB HDD. De kosten zijn ongeveer 3000ā½ per jaar.
Mijn runner
Voor de runner heb ik een VDS genomen met 4 CPU's, 4 GB RAM, 50 GB SSD. Kostte ongeveer 11000ā½ en ik heb er nooit spijt van gehad.
In totaal heb ik 7 machines. 5 bij aruba en 2 bij ihor.
Dus, we hebben een runner. Nu gaan we deze instellen.
Log in op de machine via SSH en installeer java, git, maven, gnupg2.
Installeer gitlab runner
- Maak een nieuwe groep
runnersudo groupadd runner - Maak een directory voor de maven cache en geef de groep rechten
runner
Deze stap kan worden overgeslagen als je geen meerdere runners op Ć©Ć©n machine gaat draaien.mkdir -p /usr/cache/.m2/repository chown -R :runner /usr/cache chmod -R 770 /usr/cache - Maak een gebruiker aan
gitlab-deployeren voeg deze toe aan de groeprunneruseradd -m -d /home/gitlab-deployer gitlab-deployer usermod -a -G runner gitlab-deployer - Voeg de volgende regel toe aan het bestand
/etc/ssh/sshd_configde volgende regelLaat gebruikers root@* gitlab-deployer@127.0.0.1 toe - Herstarten
sshdsystemctl restart sshd - Stel een wachtwoord in voor de gebruiker
gitlab-deployer(kan eenvoudig zijn, omdat er een beperking voor localhost geldt)passwd gitlab-deployer - Installeer 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 - Ga naar de site gitlab.com -> deploy-project -> Instellingen -> CI/CD -> Runners -> Specifieke Runners en kopieer de registratie-token
Screenshot
- Registreer de runner
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.
Vul de gitlab-ci coƶrdinator URL in (bijv. https://gitlab.com/):
https://gitlab.com/
Vul de gitlab-ci token voor deze runner in:
REGISTRATION_TOKEN
Vul de gitlab-ci beschrijving voor deze runner in:
[ih1174328.vds.myihor.ru]: Deploy Runner
Vul de gitlab-ci tags voor deze runner in (komma-gescheiden):
deploy
Runner registreren... geslaagd runner=ZvKdjJhx
Vul de uitvoerder in: docker-ssh, parallels, virtualbox, docker-ssh+machine, kubernetes, docker, ssh, docker+machine, shell:
shell
Runner succesvol geregistreerd. Voel je vrij om deze te starten, maar als deze al draait, zou de configuratie automatisch opnieuw geladen moeten worden!- Controleer of de runner geregistreerd is. Ga naar de site gitlab.com -> deploy-project -> Instellingen -> CI/CD -> Runners -> Specifieke Runners -> Runners geactiveerd voor dit project
Screenshot
- Voeg toe afzonderlijk service
/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 - Start de service.
systemctl enable gitlab-deployer.service systemctl start gitlab-deployer.service systemctl status gitlab-deployer.service - Controleer of de runner draait.
Voorbeeld
Genereren van GPG-sleutels
- Log in met SSH als gebruiker
gitlab-deployer(dit is belangrijk voor het genereren van de GPG-sleutel)ssh gitlab-deployer@127.0.0.1 - Genereer een sleutel door de vragen te beantwoorden. Ik gebruikte mijn eigen naam en e-mail.
Zorg ervoor dat je een wachtwoord voor de sleutel opgeeft. Deze sleutel zal gebruikt worden om artefacten te ondertekenen.gpg --gen-key - Controleer
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 - Upload onze openbare sleutel naar de sleutelserver
gpg --keyserver keys.gnupg.net --send-key 00000000 gpg: sleutel 00000000 verzenden naar hkp-server keys.gnupg.net
Configuratie van Maven
- Log in als gebruiker
gitlab-deployersu gitlab-deployer - Creƫer een maven directory repository en link deze met de cache (maak geen fout)
Deze stap kan worden overgeslagen als je niet van plan bent meerdere runners op dezelfde machine te draaien.mkdir -p ~/.m2/repository ln -s /usr/cache/.m2/repository /home/gitlab-deployer/.m2/repository - Maak een masterwachtwoord aan
mvn --encrypt-master-password wachtwoord {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Maak het bestand ~/.m2/settings-security.xml aan
{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Versleutel het wachtwoord van het Sonatype-account
mvn --encrypt-password SONATYPE_PASSWORD {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J} - Maak het bestand ~/.m2/settings.xml aan
env true GPG_SECRET_KEY_PASSPHRASE sonatype SONATYPE_USERNAME {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}
waar,
GPG_SECRET_KEY_PASSPHRASE ā wachtwoord voor de GPG-sleutel
SONATYPE_USERNAME ā gebruikersnaam voor het Sonatype-account
De configuratie van de runner is nu voltooid, laten we doorgaan naar de sectie
Gedeelde Runner
Genereren van GPG-sleutels
- Allereerst moeten we een GPG-sleutel aanmaken. Installeer hiervoor gnupg.
yum install -y gnupg - Genereer een sleutel door de vragen te beantwoorden. Ik heb mijn eigen naam en e-mail gebruikt. Vergeet niet een wachtwoord voor de sleutel op te geven.
gpg --gen-key - Toon informatie over de sleutel
gpg --list-keys -a pub rsa3072 2019-04-24 [SC] [vervalt: 2021-04-23] 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 uid [uitgebreid] tttemp sub rsa3072 2019-04-24 [E] [vervalt: geen] - Upload onze openbare sleutel naar de sleutelserver
gpg --keyserver keys.gnupg.net --send-key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 gpg: het verzenden van sleutel 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 naar hkp-server keys.gnupg.net - Ontvang de privƩ-sleutel
gpg --export-secret-keys --armor 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 -----BEGIN PGP PRIVATE KEY BLOCK----- lQWGBFzAqp8BDADN41CPwJ/gQwiKEbyA902DKw/WSB1AvZQvV/ZFV77xGeG4K7k5 ... =2Wd2 -----END PGP PRIVATE KEY BLOCK----- - Ga naar projectinstellingen -> Instellingen -> CI/CD -> Variabelen en sla de privƩ-sleutel op als een variabele
GPG_SECRET_KEY
Configuratie van Maven
- Maak een masterwachtwoord aan
mvn --encrypt-master-password wachtwoord {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Ga naar projectinstellingen -> Instellingen -> CI/CD -> Variabelen en sla op in een variabele
SETTINGS_SECURITY_XMLde volgende regels:{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Versleutel het wachtwoord van het Sonatype-account
mvn --encrypt-password SONATYPE_PASSWORD {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J} - Ga naar projectinstellingen -> Instellingen -> CI/CD -> Variabelen en sla op in een variabele
SETTINGS_XMLde volgende regels:env true GPG_SECRET_KEY_PASSPHRASE sonatype sonatype_username {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}
waar,
GPG_SECRET_KEY_PASSPHRASE ā wachtwoord voor de GPG-sleutel
SONATYPE_USERNAME ā gebruikersnaam voor het Sonatype-account
Docker-afbeelding implementeren
- Maak een eenvoudig genoeg Dockerfile aan om taken uit te voeren met de vereiste versie van Java. Hieronder een voorbeeld voor alpine.
FROM java:8u111-jdk-alpine RUN apk add gnupg maven git --update-cache --repository http://dl-4.alpinelinux.org/alpine/edge/community/ --allow-untrusted && mkdir ~/.m2/ - We bouwen een container voor uw project
docker build -t registry.gitlab.com/group/deploy . - We authenticeren ons en uploaden de container naar de registry.
docker login -u USER -p PASSWORD registry.gitlab.com docker push registry.gitlab.com/group/deploy
GitLab CI
Project implementeren
Voeg het bestand .gitlab-ci.yml toe aan de root van het deploy-project
In het script zijn er twee wederzijds exclusieve taken voor de deploy. Specific Runner of Shared Runner, respectievelijk.
.gitlab-ci.yml
stages:
- deploy
Specific Runner:
extends: .java_deploy_template
# Dit taak zal worden uitgevoerd op uw shell-runner
tags:
- deploy
Shared Runner:
extends: .java_deploy_template
# Dit taak zal worden uitgevoerd op de publieke docker-runner
tags:
- docker
# Image uit het gedeelte GitLab Runner -> Shared Runner -> Docker
image: registry.gitlab.com/group/deploy-project:latest
before_script:
# Importeer de GPG sleutel
- printf "${GPG_SECRET_KEY}" | gpg --batch --import
# Sla de maven-configuratie op
- printf "${SETTINGS_SECURITY_XML}" > ~/.m2/settings-security.xml
- printf "${SETTINGS_XML}" > ~/.m2/settings.xml
.java_deploy_template:
stage: deploy
# Dit taak zal worden geactiveerd op trigger, als de variabele DEPLOY met de waarde java is doorgegeven
only:
variables:
- $DEPLOY == "java"
variables:
# klonen van het huidige project uitschakelen
GIT_STRATEGY: none
script:
# Bied de mogelijkheid om het wachtwoord in onversleutelde vorm op te slaan
- git config --global credential.helper store
# Sla tijdelijke referenties van gebruiker gitlab-ci-token op
# De token werkt voor alle publieke projecten op gitlab.com en voor groepsprojecten
- echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" >> ~/.git-credentials
# Maak de huidige directory volledig schoon
- rm -rf .* *
# Clone het project dat we gaan deployen naar Sonatype Nexus
- git clone ${DEPLOY_CI_REPOSITORY_URL} .
# Schakel over naar de juiste commit
- git checkout ${DEPLOY_CI_COMMIT_SHA} -f
# Als een pom.xml de parameter autoReleaseAfterClose bevat, zal de build falen.
# Anders bestaat het risico om ruwe artefacten in maven central te uploaden
- >
for pom in $(find . -name pom.xml); do
if [[ $(grep -q autoReleaseAfterClose "$pom" && echo $?) == 0 ]]; then
echo "Bestand $pom bevat een verboden instelling: ";
exit 1;
fi;
done
# Als de parameter DEPLOY_CI_COMMIT_TAG leeg is, stellen we handmatig de SNAPSHOT-versie in
- >
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
# Start de taak voor het bouwen en deployment van artefacten
- mvn clean deploy -DskipTests=trueJava-project
In Java-projecten die bedoeld zijn om in openbare repositories te worden geĆ¼pload, moeten 2 stappen worden toegevoegd voor het uploaden van Release- en Snapshot-versies.
.gitlab-ci.yml
stages:
- build
- test
- verify
- deploy
Release:
extends: .trigger_deploy
# Taak alleen starten op basis van tag.
only:
- tags
Snapshot:
extends: .trigger_deploy
# Taak handmatig starten voor publicatie van SNAPSHOT-versie
when: manual
# Taak niet starten als er een tag is ingesteld.
except:
- tags
.trigger_deploy:
stage: deploy
variables:
# Klonen van het huidige project uitschakelen
GIT_STRATEGY: none
# Link naar de trigger van de deploy-taak
URL: "https://gitlab.com/api/v4/projects//trigger/pipeline"
# Variabelen voor de deploy-taak
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:
# Gebruik geen cURL, want met de vlaggen --fail --show-error
# geeft het geen reactie terug als de HTTP-code 400 of hoger is
- wget --content-on-error -qO- ${URL} --post-data ${POST_DATA}In deze oplossing ben ik een stap verder gegaan en heb ik besloten om Ć©Ć©n CI-sjabloon te gebruiken voor Java-projecten.
Meer gedetailleerd
Ik heb een apart project aangemaakt waar ik het CI-sjabloon voor Java-projecten heb geplaatst .
common.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
Daardoor ziet het .gitlab-ci.yml bestand in de java-projecten er vrij compact en niet te langdradig uit.
.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_deployConfiguratie van pom.xml
Dit onderwerp wordt zeer gedetailleerd besproken. in , daarom zal ik enkele nuances van het gebruik van plugins beschrijven. Ook zal ik uitleggen hoe gemakkelijk en ontspannen je het kunt gebruiken. nexus-staging-maven-plugin, als je org.sonatype.oss:oss-parent niet wilt of kunt gebruiken als ouder voor je project.
maven-install-plugin
Installeert modules in de lokale repository.
Zeer nuttig voor lokale verificatie van oplossingen in andere projecten, alsook voor de controle som.
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 generatie voor het project.
org.apache.maven.plugins
maven-javadoc-plugin
jar
prepare-package
true
true
falseAls u een module heeft die geen java bevat (bijvoorbeeld alleen resources)
Of als u helemaal geen javadoc wilt genereren, dan is dit nuttig 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
Configuratie:
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/Als u een multimodulproject heeft en u heeft geen behoefte om een bepaalde module naar de repository te uploaden, moet u het volgende aan de pom.xml van deze module toevoegen nexus-staging-maven-plugin met de vlag skipNexusStagingDeployMojo
org.sonatype.plugins
nexus-staging-maven-plugin
trueNa het uploaden zijn snapshot/release versies beschikbaar in
SonatypeNexus
https://oss.sonatype.org/content/groups/staging/Nog meer voordelen
- Een zeer uitgebreide lijst van doelen voor het werken met de nexus repository (
mvn help:describe -Dplugin=org.sonatype.plugins:nexus-staging-maven-plugin). - Automatische controle van de release op geschiktheid voor upload naar maven central
Resultaat
Publicatie van de SNAPSHOT versie
Bij het bouwen van het project is er een mogelijkheid voor handmatige uitvoering van de taak om de SNAPSHOT versie naar nexus te uploaden
Bij het uitvoeren van deze taak wordt de overeenkomstige taak in het project deploy geactiveerd ().
Ingekorte log
Uitvoering met gitlab-runner 11.10.0 (3001a600)
op Deploy runner JSKWyxUw
Gebruik van Shell executor...
Uitvoeren op ih1174328.vds.myihor.ru...
Overslaan van de Git-repository-instelling
Overslaan van Git-checkout
Overslaan van de instelling van Git-submodules
$ 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} .
Klonen in 'shields4j'...
$ git checkout ${DEPLOY_CI_COMMIT_SHA}
Opmerking: uitchecken '850f86aa317194395c5387790da1350e437125a7'.
Je bevindt je in de 'detached HEAD' status. Je kunt rondkijken, experimentele
wijzigingen aanbrengen en ze committen, en je kunt commits die je in deze
status maakt weggooien zonder invloed op branches door een andere checkout uit te voeren.
Als je een nieuwe branch wilt maken om de commits die je maakt te behouden, kun je
dit doen (nu of later) door -b te gebruiken met het checkout-commando opnieuw. Voorbeeld:
git checkout -b new_branch_name
HEAD staat nu op 850f86a... overslaan implentatietest-core
$ voor pom in $(find . -name pom.xml); doe # ingekorte multi-line opdracht
$ als [[ "${DEPLOY_CI_COMMIT_TAG}" != "" ]]; dan # ingekorte multi-line opdracht
[INFO] Scannen naar projecten...
[INFO] Inspecteren van build met in totaal 4 modules...
[INFO] Instellen van Nexus Staging-functies:
[INFO] ... in totaal 4 uitvoeringen van maven-deploy-plugin vervangen door 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] -----------------------------
[INFO] Bouwen van Shields4J 1.0.0 [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- versions-maven-plugin:2.5:set (default-cli) @ shields4j-parent ---
[INFO] Zoeken naar lokale aggregator root...
[INFO] Lokale aggregatie root: /home/gitlab-deployer/JSKWyxUw/0/TouchBIT/deploy/shields4j
[INFO] Verwerken van wijziging van org.touchbit.shields4j:shields4j-parent:1.0.0 -> 1.0.0-SNAPSHOT
[INFO] Verwerken van org.touchbit.shields4j:shields4j-parent
[INFO] Bijwerken van project org.touchbit.shields4j:shields4j-parent
[INFO] van versie 1.0.0 naar 1.0.0-SNAPSHOT
[INFO]
[INFO] Verwerken van org.touchbit.shields4j:client
[INFO] Bijwerken van ouder org.touchbit.shields4j:shields4j-parent
[INFO] van versie 1.0.0 naar 1.0.0-SNAPSHOT
[INFO] Bijwerken van afhankelijkheid org.touchbit.shields4j:test-core
[INFO] van versie 1.0.0 naar 1.0.0-SNAPSHOT
[INFO]
[INFO] Verwerken van org.touchbit.shields4j:test-core
[INFO] Bijwerken van ouder org.touchbit.shields4j:shields4j-parent
[INFO] van versie 1.0.0 naar 1.0.0-SNAPSHOT
[INFO]
[INFO] Verwerken van org.touchbit.shields4j:testng
[INFO] Bijwerken van ouder org.touchbit.shields4j:shields4j-parent
[INFO] van versie 1.0.0 naar 1.0.0-SNAPSHOT
[INFO] Bijwerken van afhankelijkheid org.touchbit.shields4j:client
[INFO] van versie 1.0.0 naar 1.0.0-SNAPSHOT
[INFO] Bijwerken van afhankelijkheid org.touchbit.shields4j:test-core
[INFO] van versie 1.0.0 naar 1.0.0-SNAPSHOT
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Samenvatting:
[INFO]
[INFO] Shields4J 1.0.0 .................................... SUCCES [ 0.992 s]
[INFO] test-core .......................................... OVERGESLAGEN
[INFO] Shields4J-client ................................... OVERGESLAGEN
[INFO] TestNG listener 1.0.0 .............................. OVERGESLAGEN
[INFO] ------------------------------------------------------------------------
[INFO] BOUW SUCCES
[INFO] ------------------------------------------------------------------------
[INFO] Totale tijd: 2.483 s
[INFO] Geƫindigd op: 2019-04-21T02:40:42+03:00
[INFO] ------------------------------------------------------------------------
$ mvn clean deploy -DskipTests=${SKIP_TESTS}
[INFO] Scannen naar projecten...
[INFO] Inspecteren van build met in totaal 4 modules...
[INFO] Instellen van Nexus Staging-functies:
[INFO] ... in totaal 4 uitvoeringen van maven-deploy-plugin vervangen door 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] -----------------------------
[INFO] Bouwen van Shields4J 1.0.0-SNAPSHOT [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
...
VERWIJ GEDAAN
...
[INFO] * Bulk-implementatie van lokaal verzamelde snapshot-artikelen voltooid.
[INFO] Afstandsimplementatie voltooid met succes.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Samenvatting:
[INFO]
[INFO] Shields4J 1.0.0-SNAPSHOT ........................... SUCCES [ 2.375 s]
[INFO] test-core .......................................... SUCCES [ 3.929 s]
[INFO] Shields4J-client ................................... SUCCES [ 3.815 s]
[INFO] TestNG listener 1.0.0-SNAPSHOT ..................... SUCCES [ 36.134 s]
[INFO] ------------------------------------------------------------------------
[INFO] BOUW SUCCES
[INFO] ------------------------------------------------------------------------
[INFO] Totale tijd: 47.629 s
[INFO] Geƫindigd op: 2019-04-21T02:41:32+03:00
[INFO] ------------------------------------------------------------------------Als resultaat is de versie in nexus geladen .
Alle snapshot versies kunnen uit de repository op de site worden verwijderd onder uw account.
Publicatie van releaseversie
Bij het instellen van het label wordt automatisch de bijbehorende taak in het project deploy geactiveerd om de releaseversie in nexus te uploaden ().
Het mooiste is dat de close release in nexus automatisch wordt geactiveerd.
[INFO] Remote staging uitvoeren...
[INFO]
[INFO] * Remote staging in staging-profiel ID "9043b43f77dcc9"
[INFO] * Stagingrepository aangemaakt met ID "orgtouchbit-1037".
[INFO] * Stagingrepository op https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1037
[INFO] * Uploaden van lokaal gestageerde artifacts naar profiel org.touchbit
[INFO] * Upload van lokaal gestageerde artifacts voltooid.
[INFO] * Sluiten van stagingrepository met ID "orgtouchbit-1037".
Wachten op voltooiing van de operatie...
.........
[INFO] Remote gestageerde 1 repositories, voltooid met succes.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Samenvatting:
[INFO]
[INFO] Shields4J 1.0.0 .................................... SUCCES [ 9.603 s]
[INFO] test-core .......................................... SUCCES [ 3.419 s]
[INFO] Shields4J client ................................... SUCCES [ 9.793 s]
[INFO] TestNG listener 1.0.0 .............................. SUCCES [01:23 min]
[INFO] ------------------------------------------------------------------------
[INFO] BOUW SUCCES
[INFO] ------------------------------------------------------------------------
[INFO] Totale tijd: 01:47 min
[INFO] Voltooid op: 2019-04-21T04:05:46+03:00
[INFO] ------------------------------------------------------------------------En als er iets misgaat, zal de taak zeker falen
[INFO] Uitvoeren van remote staging...
[INFO]
[INFO] * Remote staging naar staging-profiel ID "9043b43f77dcc9"
[INFO] * Stagingrepository aangemaakt met ID "orgtouchbit-1038".
[INFO] * Stagingrepository op https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1038
[INFO] * Uploaden van lokaal gestageerde artifacts naar profiel org.touchbit
[INFO] * Upload van lokaal gestageerde artifacts voltooid.
[INFO] * Sluiten van stagingrepository met ID "orgtouchbit-1038".
Wachten tot de bewerking is voltooid...
.......
[ERROR] Regel fout tijdens het proberen te sluiten van de stagingrepository met ID "orgtouchbit-1039".
[ERROR]
[ERROR] Nexus Staging Regels Fout Rapport
[ERROR] ==================================
[ERROR]
[ERROR] Repository "orgtouchbit-1039" fouten
[ERROR] Regel "signature-staging" fouten
[ERROR] * Geen openbare sleutel: Sleutel met id: (1f42b618d1cbe1b5) kon niet worden gevonden op <a href=http://keys.gnupg.net:11371/>http://keys.gnupg.net:11371/<\/a>. Upload uw openbare sleutel en probeer de bewerking opnieuw.
...
[ERROR] Opruimen van lokale stage-map na een Regel fout tijdens het sluiten van staging repositories: [orgtouchbit-1039]
[ERROR] * Verwijderen van context 9043b43f77dcc9.properties
[ERROR] Opruimen van remote stage repositories na een Regel fout tijdens het sluiten van staging repositories: [orgtouchbit-1039]
[ERROR] * Verwijderen van de mislukte stagingrepository met ID "orgtouchbit-1039" (Regel fout tijdens het sluiten van staging repositories: [orgtouchbit-1039]).
[ERROR] Remote staging is geƫindigd met een fout: Staging regels fout!
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Samenvatting:
[INFO]
[INFO] Shields4J 1.0.0 .................................... SUCCES [ 4.073 s]
[INFO] test-core .......................................... SUCCES [ 2.788 s]
[INFO] Shields4J client ................................... SUCCES [ 3.962 s]
[INFO] TestNG listener 1.0.0 .............................. Mislukt [01:07 min]
[INFO] ------------------------------------------------------------------------
[INFO] BOUW Mislukt
[INFO] ------------------------------------------------------------------------Hierdoor blijft ons slechts Ć©Ć©n keuze over. Of we deze versie verwijderen of publiceer.
Na de release zullen na enige tijd de artifacts beschikbaar zijn in
off-topic
Het was voor mij een ontdekking dat maven andere openbare repositories indexeert.
Ik moest robots.txt toevoegen, want het had mijn oude repository geĆÆndexeerd.
Conclusie
Wat hebben we
- Een apart deploy-project waarin meerdere CI-taken kunnen worden uitgevoerd voor het uploaden van artifacts naar openbare repositories voor verschillende programmeertalen.
- Het deploy-project is geĆÆsoleerd van externe inmenging en kan alleen worden gewijzigd door gebruikers met de rol Owner en Maintainer.
- Een aparte Specific Runner met een āhotā cache voor het uitvoeren van alleen deploy-taken.
- Publicatie van snapshot/release versies in een openbare repository.
- Automatische controle van de releaseversie op geschiktheid voor publicatie in maven central.
- Bescherming tegen automatische publicatie van āruweā versies in maven central.
- Bouwen en publicatie van snapshot versies āmet een klikā.
- Een enkele repository voor het verkrijgen van snapshot/release versies.
- Algemene pipeline voor het bouwen/testen/publiceren van een Java-project.
Het instellen van GitLab CI is niet zo'n moeilijk onderwerp als het op het eerste gezicht lijkt. Het volstaat om een paar keer CI "sleutel-klaar" in te stellen en je bent al een heel eind op weg. Bovendien is de documentatie van GitLab vrij uitgebreid. Wees niet bang om de eerste stap te zetten. De weg ontstaat onder de stappen van degene die loopt (ik weet niet meer wie dat zei š ).
Ik ontvang graag feedback.
In het volgende artikel zal ik uitleggen hoe je GitLab CI kunt instellen voor gelijktijdige uitvoering van taken met integratietests (met het starten van de te testen services via docker-compose), als je slechts Ć©Ć©n shell-runner hebt.
Bron: habr.com
