Denne artikel er rettet mod java-udviklere, som har behov for hurtigt at publicere deres produkter i sonatype og/eller maven central ved hjælp af GitLab. I denne artikel vil jeg beskrive opsætningen af gitlab-runner, gitlab-ci og maven-plugin til at løse denne opgave.
Forudsætninger:
- Sikker opbevaring af mvn og GPG-nøgler.
- Sikker udførelse af offentlige CI-opgaver.
- Upload af artefakter (release/snapshot) til offentlige repositories.
- Automatisk kontrol af release-versioner til publicering i maven central.
- Generelt løsning til upload af artefakter til repository for flere projekter.
- Simplicitet og brugervenlighed.
Indhold
Generell informasjon
- En detaljeret beskrivelse af publiceringsmekanismen for artefakter i Maven Central gennem Sonatype OSS Repository Hosting Service er allerede beskrevet i brugeren , derfor vil jeg referere til denne artikel på de relevante steder.
- Foreløbigt registrerer vi os i og opretter en ticket til åbning af repository (læs mere i afsnit ). Efter åbning af repository vil et login/password fra JIRA (senere Sonatype-konto) blive brugt til at uploade artefakter til Sonatype nexus.
- Processen til generering af GPG-nøgler er beskrevet ret tørt. For mere information, se afsnit
- Hvis du bruger Linux-konsollen til at generere GPG-nøglen (gnupg/gnupg2), skal du installere for at generere entropi. Ellers kan genereringen af nøglen tage meget lang tid.
- Opbevaringstjenester offentlige GPG-nøgler
Opsætning af deploy-projekt i GitLab
- Først skal du oprette og konfigurere et projekt, hvor pipeline til deployment af artefakterne vil blive opbevaret. Jeg navngav mit projekt enkelt og ligetil —
- Efter oprettelse af repository skal adgangen til at ændre repository begrænses.
Gå til projektet -> Indstillinger -> Repository -> Beskyttede grene. Fjern alle regler og tilføj kun én regel med wildcard * med adgang til push og merge kun for brugere med rollen Maintainer. Denne regel vil gælde for alle brugere i både dette projekt og den gruppe, som dette projekt tilhører.
- Hvis der er flere maintainers, er det bedste valg at begrænse adgangen til projektet generelt.
Gå til projektet -> Indstillinger -> Generelt -> Synlighed, projektfunktioner, tilladelser og indstil Projekt synlighed til værdien Privat.
Jeg har et projekt, der er offentligt tilgængeligt, da jeg bruger min egen GitLab Runner, og adgang til at ændre repositoryet har kun jeg. Og det er ikke i mine interesser at eksponere privat information i offentlige pipeline-logfiler. - Stramning af reglerne for ændring af repositoryet
Gå til projektet -> Indstillinger -> Repository -> Push-regler og aktiverer flg. Kommitteringsrestriktion, Tjek om forfatteren er en GitLab-bruger. Jeg anbefaler også at konfigurere , og aktivere flaget Afvis usignerede commits. - Derudover er det nødvendigt at konfigurere en trigger til at starte opgaver
Gå til projektet -> Indstillinger -> CI / CD -> Pipeline-triggere og opret en ny trigger-token
Denne token kan straks tilføjes til den overordnede konfiguration af variabler for gruppeprojekterne.
Gå til gruppen -> Indstillinger -> CI / CD -> Variabler og tilføj variablenDEPLOY_TOKENmed trigger-token i værdien.
GitLab Runner
I denne sektion er konfigurationen for at køre opgaver på deploy med brug af en egen (Specific) og offentlig (Shared) runner beskrevet.
Specific Runner
Jeg bruger egne runners, da det først og fremmest er praktisk, hurtigt og billigt.
Til runneren anbefaler jeg en Linux VDS med 1 CPU, 2 GB RAM, 20 GB HDD. Prisen er ca. 3000₽ om året.
Min runner
Til runneren tog jeg en VDS med 4 CPU, 4 GB RAM, 50 GB SSD. Det kostede omkring 11000₽, og jeg har aldrig fortrudt det.
Jeg har i alt 7 maskiner. 5 hos aruba og 2 hos ihor.
Så vi har en runner. Nu skal vi konfigurere den.
Log ind på maskinen via SSH og installer java, git, maven, gnupg2.
Installer gitlab runner
- Opret en ny gruppe
runnersudo groupadd runner - Opret en mappe til maven cache og tildel gruppeadgang
runner
Dette punkt kan springes over, hvis du ikke planlægger at køre flere runners på samme maskine.mkdir -p /usr/cache/.m2/repository chown -R :runner /usr/cache chmod -R 770 /usr/cache - Opret en bruger
gitlab-deployerog tilføj den til gruppenrunneruseradd -m -d /home/gitlab-deployer gitlab-deployer usermod -a -G runner gitlab-deployer - Tilføj følgende linje til filen
/etc/ssh/sshd_config.TilladBrugere root@* gitlab-deployer@127.0.0.1 - Genstarter
sshdsystemctl genstart sshd - Opretter adgangskode for brugeren
gitlab-deployer(kan være simpel, da der er en begrænsning for localhost)passwd gitlab-deployer - Installerer 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 - Går til hjemmesiden gitlab.com -> deploy-project -> Indstillinger -> CI/CD -> Runners -> Specifikke Runners og kopierer registreringstokenet
Skærm
- Registrerer 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
Kører i system-mode.
Indtast venligst gitlab-ci koordinator URL (f.eks. https://gitlab.com/):
https://gitlab.com/
Indtast venligst gitlab-ci token for denne runner:
REGISTRATION_TOKEN
Indtast venligst gitlab-ci beskrivelse for denne runner:
[ih1174328.vds.myihor.ru]: Deploy Runner
Indtast venligst gitlab-ci tags for denne runner (kommasepareret):
deploy
Registrering af runner... lykkedes runner=ZvKdjJhx
Indtast venligst executor: docker-ssh, parallels, virtualbox, docker-ssh+machine, kubernetes, docker, ssh, docker+machine, shell:
shell
Runner registreret med succes. Du kan starte den, men hvis den allerede kører, skal konfigurationen automatisk genindlæses!- Tjekker, om runneren er registreret. Går til hjemmesiden gitlab.com -> deploy-project -> Indstillinger -> CI/CD -> Runners -> Specifikke Runners -> Runners aktiveret for dette projekt
Skærm
- Tilføjer separat 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 - Starter tjenesten.
systemctl enable gitlab-deployer.service systemctl start gitlab-deployer.service systemctl status gitlab-deployer.service - Tjekker, om runneren kører.
Eksempel
Generering af GPG-nøgler
- Log ind fra denne maskine via ssh som bruger
gitlab-deployer(det er vigtigt for genereringen af GPG-nøglen)ssh gitlab-deployer@127.0.0.1 - Genererer nøglen ved at besvare spørgsmålene. Jeg brugte mit eget navn og e-mail.
Husk at angive en adgangskode for nøglen. Denne nøgle vil blive brugt til at underskrive artefakter.gpg --gen-key - Vi tjekker
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 - Uploaderer vores offentlige nøgle til nøgleserveren
gpg --keyserver keys.gnupg.net --send-key 00000000 gpg: sending key 00000000 to hkp server keys.gnupg.net
Opsætning af Maven
- Logger ind som bruger
gitlab-deployersu gitlab-deployer - Opretter maven repository og linker til cachen (vær forsigtig)
Dette punkt kan springes over, hvis du ikke planlægger at køre flere runners på samme maskine.mkdir -p ~/ .m2/ repository ln -s /usr/cache/.m2/repository /home/gitlab-deployer/.m2/repository - Opretter masternøgle
mvn --encrypt-master-password password {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Opretter filen ~/ .m2/ settings-security.xml
{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Krypterer adgangskoden til Sonatype-kontoen
mvn --encrypt-password SONATYPE_PASSWORD {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J} - Opretter filen ~/ .m2/ settings.xml
env true GPG_SECRET_KEY_PASSPHRASE sonatype SONATYPE_USERNAME {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}
hvor,
GPG_SECRET_KEY_PASSPHRASE — adgangskode til GPG-nøglen
SONATYPE_USERNAME — brugernavn til sonatype-kontoen
Konfigurationen af runneren er nu afsluttet, vi kan gå videre til sektionen
Shared Runner
Generering af GPG-nøgler
- Først skal vi oprette en GPG-nøgle. Til dette skal vi installere gnupg.
yum install -y gnupg - Generer nøglen ved at besvare spørgsmålene. Jeg brugte mit eget navn og email. Sørg for at angive en adgangskode til nøglen.
gpg --gen-key - Viser information om nøglen.
gpg --list-keys -a pub rsa3072 2019-04-24 [SC] [udløber: 2021-04-23] 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 uid [ultimate] tttemp sub rsa3072 2019-04-24 [E] [udløber: ingen] - Uploaderer vores offentlige nøgle til nøgleserveren
gpg --keyserver keys.gnupg.net --send-key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 gpg: sender nøgle 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 til hkp-server keys.gnupg.net - Henter den private nøgle
gpg --export-secret-keys --armor 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 -----BEGIN PGP PRIVATE KEY BLOCK----- lQWGBFzAqp8BDADN41CPwJ/gQwiKEbyA902DKw/WSB1AvZQvV/ZFV77xGeG4K7k5 ... =2Wd2 -----END PGP PRIVATE KEY BLOCK----- - Gå til projektindstillinger -> Indstillinger -> CI / CD -> Variabler og gem den private nøgle i variablen
GPG_SECRET_KEY
Opsætning af Maven
- Opretter masternøgle
mvn --encrypt-master-password password {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Gå til projektindstillinger -> Indstillinger -> CI / CD -> Variabler og gem i variablen
SETTINGS_SECURITY_XMLfølgende linjer:{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Krypterer adgangskoden til Sonatype-kontoen
mvn --encrypt-password SONATYPE_PASSWORD {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J} - Gå til projektindstillinger -> Indstillinger -> CI / CD -> Variabler og gem i variablen
SETTINGS_XMLfølgende linjer:env true GPG_SECRET_KEY_PASSPHRASE sonatype sonatype_username {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}
hvor,
GPG_SECRET_KEY_PASSPHRASE — adgangskode til GPG-nøglen
SONATYPE_USERNAME — brugernavn til sonatype-kontoen
Deploy docker image
- Opretter en ret simpel Dockerfile til at køre opgaver ved deployment med den nødvendige version af Java. Nedenfor er et eksempel for alpine.
FRA 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/ - Vi bygger en container til dit projekt
docker build -t registry.gitlab.com/group/deploy . - Vi autentificerer os og uploader containeren til registry.
docker login -u USER -p PASSWORD registry.gitlab.com docker push registry.gitlab.com/group/deploy
GitLab CI
Deploy projekt
Tilføj filen .gitlab-ci.yml til roden af deploy-projektet
Scriptet indeholder to gensidigt udelukkende opgaver til deployment. Specifik Runner eller Delt Runner henholdsvis.
.gitlab-ci.yml
stages:
- deploy
Specifik Runner:
extends: .java_deploy_template
# Opgaven udføres på din shell-runner
tags:
- deploy
Delt Runner:
extends: .java_deploy_template
# Opgaven udføres på en offentlig docker-runner
tags:
- docker
# Billedet fra sektionen GitLab Runner -> Delt Runner -> Docker
image: registry.gitlab.com/group/deploy-project:latest
before_script:
# Importer GPG-nøglen
- printf "${GPG_SECRET_KEY}" | gpg --batch --import
# Gemmer maven-konfigurationen
- printf "${SETTINGS_SECURITY_XML}" > ~/.m2/settings-security.xml
- printf "${SETTINGS_XML}" > ~/.m2/settings.xml
.java_deploy_template:
stage: deploy
# Opgaven vil aktiveres ved trigger, hvis variablen DEPLOY har værdien java
only:
variables:
- $DEPLOY == "java"
variables:
# Deaktiverer kloning af det nuværende projekt
GIT_STRATEGY: none
script:
# Giver mulighed for at gemme adgangskoden i ukrypteret form
- git config --global credential.helper store
# Gemmer midlertidigt brugeren gitlab-ci-token's credentials
# Tokenet fungerer for alle offentlige projekter gitlab.com og for gruppeprojekter
- echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" >> ~/.git-credentials
# Rydder helt op i den nuværende mappe
- rm -rf .* *
# Kloner projektet som skal deployes til Sonatype Nexus
- git clone ${DEPLOY_CI_REPOSITORY_URL} .
# Skifter til den ønskede commit
- git checkout ${DEPLOY_CI_COMMIT_SHA} -f
# Hvis nogen pom.xml indeholder parameteren autoReleaseAfterClose, afbryder vi byggeriet.
# Ellers er der risiko for at uploade rå artefakter til maven central
- >
for pom in $(find . -name pom.xml); do
if [[ $(grep -q autoReleaseAfterClose "$pom" && echo $?) == 0 ]]; then
echo "Fil $pom indeholder forbudt indstilling: ";
exit 1;
fi;
done
# Hvis parameteren DEPLOY_CI_COMMIT_TAG er tom, tvinger vi SNAPSHOT-versionen
- >
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
# Kører opgaven for at bygge og deploye artefakter
- mvn clean deploy -DskipTests=trueJava projekt
I Java-projekter, der skal uploades til offentlige repository, skal der tilføjes 2 trin til upload af Release- og Snapshot-versioner.
.gitlab-ci.yml
stages:
- build
- test
- verify
- deploy
Release:
extends: .trigger_deploy
# Kør opgaven kun på tag.
only:
- tags
Snapshot:
extends: .trigger_deploy
# Vi kører opgaven til offentliggøring af SNAPSHOT-versionen manuelt
when: manual
# Kør ikke opgaven, hvis et tag er angivet.
except:
- tags
.trigger_deploy:
stage: deploy
variables:
# Deaktiver kloning af nuværende projekt
GIT_STRATEGY: none
# Link til trigger deploy-opgave
URL: "https://gitlab.com/api/v4/projects//trigger/pipeline"
# Variabler til deploy-opgaven
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:
# Jeg bruger ikke cURL, da den med flagene --fail --show-error
# ikke viser svarkroppen, hvis HTTP-koden er 400 eller højere
- wget --content-on-error -qO- ${URL} --post-data ${POST_DATA}I denne løsning gik jeg lidt videre og besluttede at bruge en CI-skabelon til Java-projekter.
Mere detaljeret
Jeg oprettede et separat projekt hvor jeg placerede CI-skabelonen for Java-projekter .
common.yml
faser:
- opbygning
- test
- verifikation
- implementering
variabler:
SONAR_ARGS: "
-Dsonar.gitlab.commit_sha=${CI_COMMIT_SHA}
-Dsonar.gitlab.ref_name=${CI_COMMIT_REF_NAME}
"
.build_java_project:
niveau: opbygning
tags:
- touchbit-shell
variabler:
SKIP_TEST: "false"
script:
- mvn clean
- mvn pakke -DskipTests=${SKIP_TEST}
artefakter:
når: altid
udløber_efter: 30 dage
stier:
- "*\target\rapporter"
.build_sphinx_doc:
niveau: opbygning
tags:
- touchbit-shell
variabler:
DOCKERFILE: .indirect\docs\Dockerfile
script:
- docker build --no-cache -t ${CI_PROJECT_NAME}\doc -f ${DOCKERFILE} .
.junit_module_test_run:
niveau: test
tags:
- touchbit-shell
variabler:
MODUL: ""
script:
- cd ${MODUL}
- mvn test
artefakter:
når: altid
udløber_efter: 30 dage
stier:
- "*\target\rapporter"
.junit_test_run:
niveau: test
tags:
- touchbit-shell
script:
- mvn test
artefakter:
når: altid
udløber_efter: 30 dage
stier:
- "*\target\rapporter"
.sonar_review:
niveau: verifikation
tags:
- touchbit-shell
afhængigheder: []
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:
niveau: implementering
tags:
- touchbit-shell
variabler:
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
når: manuel
undtagen:
- tags
Som et resultat ser .gitlab-ci.yml i selve java projekterne ret kompakt og kortfattet ud
.gitlab-ci.yml
inkluder: https://gitlab.com/TouchBIT/gitlab-ci/raw/master/common.yml
Shields4J:
extends: .build_java_project
Sphinx doc:
extends: .build_sphinx_doc
variabler:
DOCKERFILE: .docs/Dockerfile
Sonar review:
extends: .sonar_review
afhængigheder:
- Shields4J
Udgivelse:
extends: .trigger_release_deploy
Snapshot:
extends: .trigger_snapshot_deployKonfiguration af pom.xml
Dette emne er beskrevet meget detaljeret i , så jeg vil beskrive nogle nuancer ved brug af plugins. Jeg vil også forklare, hvor let og uproblematisk det kan være at bruge nexus-staging-maven-plugin, hvis du ikke ønsker eller kan bruge org.sonatype.oss:oss-parent som forælder til dit projekt.
maven-install-plugin
Installerer moduler i det lokale repository.
Meget nyttig til lokal kontrol af løsninger i andre projekter samt checksums.
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
Generering af javadoc til projektet.
org.apache.maven.plugins
maven-javadoc-plugin
jar
prepare-package
true
true
falseHvis du har et modul, der ikke indeholder java (for eksempel kun ressourcer)
Eller hvis du slet ikke ønsker at generere javadoc, så er der hjælp her 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
Konfiguration:
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/Hvis du har et multimodulprojekt, og du ikke har brug for at uploade en bestemt modul til repositoryet, så skal du tilføje det til pom.xml for den pågældende modul. nexus-staging-maven-plugin med flag skipNexusStagingDeployMojo
org.sonatype.plugins
nexus-staging-maven-plugin
trueEfter uploaden er snapshot/release versioner tilgængelige i
SonatypeNexus
https://oss.sonatype.org/content/groups/staging/
Flere fordele
- En meget omfattende liste af mål for arbejde med nexus repositoryet (
mvn help:describe -Dplugin=org.sonatype.plugins:nexus-staging-maven-plugin). - Automatisk kontrol af release for muligheden for upload til maven central
Resultat
Publicering af SNAPSHOT version
Ved opbygning af projektet er der mulighed for manuelt at igangsætte en opgave for upload af SNAPSHOT version til nexus
Ved at starte denne opgave trigges den tilsvarende opgave i deploy-projektet ().
Afkortet log
Kører med gitlab-runner 11.10.0 (3001a600)
på Deploy runner JSKWyxUw
Bruger Shell-eksekutor...
Kører på ih1174328.vds.myihor.ru...
Springer Git-repository opsætning over
Springer Git checkout over
Springer Git submoduler opsætning over
$ 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} .
Kloner ind i 'shields4j'...
$ git checkout ${DEPLOY_CI_COMMIT_SHA}
Bemærk: checker ud '850f86aa317194395c5387790da1350e437125a7'.
Du er i 'frakoblet HEAD'-tilstand. Du kan kigge rundt, lave eksperimentelle
ændringer og committe dem, og du kan kassere eventuelle commits, du laver i denne
tilstand uden at påvirke nogle grene ved at udføre en anden checkout.
Hvis du vil oprette en ny gren for at bevare de commits, du opretter, kan du
gøre det (nu eller senere) ved at bruge -b med checkout-kommandoen igen. Eksempel:
git checkout -b new_branch_name
HEAD er nu på 850f86a... spring over deploy test-core
$ for pom in $(find . -name pom.xml); do # sammenfoldet multi-linje kommando
$ if [[ "${DEPLOY_CI_COMMIT_TAG}" != "" ]]; then # sammenfoldet multi-linje kommando
[INFO] Scanning for projects...
[INFO] Inspicerer build med i alt 4 moduler...
[INFO] Installerer Nexus Staging-funktioner:
[INFO] ... i alt 4 udførelser af maven-deploy-plugin erstattet med 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] Bygger Shields4J 1.0.0 [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- versions-maven-plugin:2.5:set (default-cli) @ shields4j-parent ---
[INFO] Søger efter lokal aggregator rod...
[INFO] Lokal aggregerings rod: /home/gitlab-deployer/JSKWyxUw/0/TouchBIT/deploy/shields4j
[INFO] Bearbejder ændringen af org.touchbit.shields4j:shields4j-parent:1.0.0 -> 1.0.0-SNAPSHOT
[INFO] Bearbejder org.touchbit.shields4j:shields4j-parent
[INFO] Opdaterer projekt org.touchbit.shields4j:shields4j-parent
[INFO] fra version 1.0.0 til 1.0.0-SNAPSHOT
[INFO]
[INFO] Bearbejder org.touchbit.shields4j:client
[INFO] Opdaterer forælder org.touchbit.shields4j:shields4j-parent
[INFO] fra version 1.0.0 til 1.0.0-SNAPSHOT
[INFO] Opdaterer afhængighed org.touchbit.shields4j:test-core
[INFO] fra version 1.0.0 til 1.0.0-SNAPSHOT
[INFO]
[INFO] Bearbejder org.touchbit.shields4j:test-core
[INFO] Opdaterer forælder org.touchbit.shields4j:shields4j-parent
[INFO] fra version 1.0.0 til 1.0.0-SNAPSHOT
[INFO]
[INFO] Bearbejder org.touchbit.shields4j:testng
[INFO] Opdaterer forælder org.touchbit.shields4j:shields4j-parent
[INFO] fra version 1.0.0 til 1.0.0-SNAPSHOT
[INFO] Opdaterer afhængighed org.touchbit.shields4j:client
[INFO] fra version 1.0.0 til 1.0.0-SNAPSHOT
[INFO] Opdaterer afhængighed org.touchbit.shields4j:test-core
[INFO] fra version 1.0.0 til 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] BYGGE SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Samlet tid: 2.483 s
[INFO] Afsluttet kl.: 2019-04-21T02:40:42+03:00
[INFO] ------------------------------------------------------------------------
$ mvn clean deploy -DskipTests=${SKIP_TESTS}
[INFO] Scanning for projects...
[INFO] Inspicerer build med i alt 4 moduler...
[INFO] Installerer Nexus Staging-funktioner:
[INFO] ... i alt 4 udførelser af maven-deploy-plugin erstattet med 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] Bygger Shields4J 1.0.0-SNAPSHOT [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
...
DELETERET
...
[INFO] * Bulk deployment af lokalt indsamlede snapshot-artikler er afsluttet.
[INFO] Fjerndistribution afsluttet med succes.
[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] BYGGE SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Samlet tid: 47.629 s
[INFO] Afsluttet kl.: 2019-04-21T02:41:32+03:00
[INFO] ------------------------------------------------------------------------Som følge heraf er der blevet uploadet en version til nexus .
Alle snapshot-versioner kan slettes fra repositoryet på hjemmesiden under din konto.
Publicering af release-version
Når taggen installeres, udløses der automatisk en tilsvarende opgave i deploy-projektet for at uploade den stabile version til nexus ().
Det mest behagelige er, at close release i nexus aktiveres automatisk.
[INFO] Udfører fjernstyring af staging...
[INFO]
[INFO] * Fjernstyring ind i staging-profil ID "9043b43f77dcc9"
[INFO] * Oprettet staging-repository med ID "orgtouchbit-1037".
[INFO] * Staging-repository på https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1037
[INFO] * Uploader lokale staging-artikler til profil org.touchbit
[INFO] * Upload af lokale staging-artikler afsluttet.
[INFO] * Lukker staging-repository med ID "orgtouchbit-1037".
Venter på, at operationen skal afsluttes...
.........
[INFO] Fjernstaged 1 repository, afsluttet med succes.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Resume:
[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] BYGGEN SUCCES
[INFO] ------------------------------------------------------------------------
[INFO] Total tid: 01:47 min
[INFO] Afsluttet den: 2019-04-21T04:05:46+03:00
[INFO] ------------------------------------------------------------------------Og hvis noget går galt, vil opgaven helt sikkert fejle
[INFO] Udfører fjernstaging...
[INFO]
[INFO] * Fjernstaging til staging-profil ID "9043b43f77dcc9"
[INFO] * Oprettet staging-repository med ID "orgtouchbit-1038".
[INFO] * Staging-repository på https://oss.sonatype.org:443/service/local/staging/deployByRepositoryId/orgtouchbit-1038
[INFO] * Upload af lokalt stageede artefakter til profil org.touchbit
[INFO] * Upload af lokalt stageede artefakter færdig.
[INFO] * Lukker staging-repository med ID "orgtouchbit-1038".
Venter på, at operationen bliver fuldført...
.......
[ERROR] Regelfejl ved forsøget på at lukke staging-repository med ID "orgtouchbit-1039".
[ERROR]
[ERROR] Nexus Staging Rules Failure Report
[ERROR] ==================================
[ERROR]
[ERROR] Repository "orgtouchbit-1039" fejl
[ERROR] Regel "signature-staging" fejl
[ERROR] * Ingen offentlig nøgle: Nøgle med id: (1f42b618d1cbe1b5) kunne ikke findes på http://keys.gnupg.net:11371/. Upload din offentlige nøgle og prøv operationen igen.
...
[ERROR] Rydder op i lokale stage-katalog efter en regelfejl under lukning af staging-repositories: [orgtouchbit-1039]
[ERROR] * Sletter kontekst 9043b43f77dcc9.properties
[ERROR] Rydder op i fjernstage-repositories efter en regelfejl under lukning af staging-repositories: [orgtouchbit-1039]
[ERROR] * Sletter mislykket staging-repository med ID "orgtouchbit-1039" (Regelfejl under lukning af staging-repositories: [orgtouchbit-1039]).
[ERROR] Fjernstaging afsluttet med en fejl: Staging-regel fejl!
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Resumé:
[INFO]
[INFO] Shields4J 1.0.0 .................................... SUCCES [ 4.073 s]
[INFO] test-core .......................................... SUCCES [ 2.788 s]
[INFO] Shields4J-klient ................................... SUCCES [ 3.962 s]
[INFO] TestNG listener 1.0.0 .............................. FEJL [01:07 min]
[INFO] ------------------------------------------------------------------------
[INFO] BYGFEJL
[INFO] ------------------------------------------------------------------------Det efterlader os med et enkelt valg. Enten at slette denne version eller offentliggøre den.
Efter udgivelsen, vil artefakterne efter et stykke tid være i
off-topic
Det var en åbenbaring for mig, at Maven indekserer andre offentlige repositoryer.
Jeg måtte tilføje robots.txt, da det indekserede mit gamle repository.
Konklusion
Hvad har vi?
- Et separat deploy-projekt hvor man kan implementere flere CI-opgaver til upload af artefakter til offentlige repositoryer for forskellige programmeringssprog.
- Deploy-projektet er isoleret fra ekstern indblanding og kan kun ændres af brugere med rollerne Owner og Maintainer.
- En separat Specific Runner med et "varmt" cache til kun at køre deploy-opgaver.
- Offentliggørelse af snapshot/release versioner i et offentligt repository.
- Automatisk kontrol af release versionens beredskab til offentliggørelse i Maven Central.
- Beskyttelse mod automatisk offentliggørelse af "rå" versioner i Maven Central.
- Bygning og offentliggørelse af snapshot versioner "med et klik".
- Et enkelt repository til at få snapshot/release versioner.
- Den overordnede pipeline til opbygning/test/publicering af Java-projekt.
Opsætning af GitLab CI er ikke så svært, som det ser ud ved første øjekast. Det er ganske enkelt at opsætte CI 'nøglefærdigt' et par gange, og så er du ikke længere en nybegynder på området. Desuden er GitLab-dokumentationen meget omfattende. Vær ikke bange for at tage det første skridt. Vejen viser sig under den gående (jeg kan ikke huske, hvem der sagde det 🙂 ).
Jeg ser frem til feedback.
I den næste artikel vil jeg forklare, hvordan du opsætter GitLab CI til at køre opgaver parallelt med integrationstest (med kørsel af de testede tjenester ved hjælp af docker-compose), hvis du kun har én shell runner.
Kilde: habr.com
