Este artigo é destinado a desenvolvedores java que precisam publicar rapidamente seus produtos em repositórios centrais sonatype e/ou maven usando GitLab. Neste artigo, falarei sobre como configurar o gitlab-runner, o gitlab-ci e o maven-plugin para resolver esse problema.
Pré-requisitos:
- Armazenamento seguro de chaves mvn e GPG.
- Execução segura de tarefas públicas de CI.
- Upload de artefatos (versão/instantâneo) para repositórios públicos.
- Verificação automática de versões de lançamento para publicação no maven central.
- Uma solução geral para fazer upload de artefatos para um repositório para vários projetos.
- Simplicidade e facilidade de uso.
Conteúdo
Informações gerais
- Uma descrição detalhada do mecanismo de publicação de artefatos no Maven Central via Sonatype OSS Repository Hosting Service já foi descrita em do utilizador , então vou me referir a este artigo nos lugares certos.
- Faça sua pré-inscrição em e inicie um ticket para abrir o repositório (para mais detalhes, leia a seção ). Depois de abrir o repositório, o par login/senha do JIRA (doravante denominado conta Sonatype) será usado para fazer upload de artefatos para o Sonatype nexus.
- Além disso, o processo de geração de uma chave GPG é descrito de forma muito seca. Consulte a seção para obter mais detalhes.
- Se você estiver usando o console Linux para gerar uma chave GPG (gnupg/gnupg2), será necessário instalar para gerar entropia. Caso contrário, a geração de chaves poderá demorar muito.
- Serviços de armazenamento público Chaves GPG
Configurando um projeto de implantação no GitLab
- Primeiramente, é necessário criar e configurar um projeto no qual será armazenado o pipeline para implantação dos artefatos. Chamei meu projeto de forma simples e descomplicada -
- Depois de criar o repositório, você precisa restringir o acesso para alterar o repositório.
Vá para o projeto -> Configurações -> Repositório -> Ramos Protegidos. Excluímos todas as regras e adicionamos uma única regra com Wildcard * com direito de push e merge apenas para usuários com função de Mantenedores. Esta regra funcionará para todos os usuários deste projeto e do grupo ao qual este projeto pertence.
- Se houver vários mantenedores, a melhor solução seria, em princípio, restringir o acesso ao projeto.
Vá para projeto -> Configurações -> Geral -> Visibilidade, recursos do projeto, permissões e defina a visibilidade do projeto como Privado.
Tenho um projeto em acesso público, pois utilizo meu próprio GitLab Runner e somente eu tenho acesso para modificar o repositório. Bem, na verdade não é do meu interesse mostrar informações privadas em registros de pipelines públicos. - Apertando as regras para alteração do repositório
Vá para o projeto -> Configurações -> Repositório -> Regras de Push e defina os sinalizadores Restrição do Committer, Verifique se o autor é um usuário do GitLab. Eu também recomendo configurar e defina o sinalizador Rejeitar confirmações não assinadas. - Em seguida, você precisa configurar um gatilho para executar tarefas
Vá para projeto -> Configurações -> CI / CD -> Gatilhos de pipeline e crie um novo token de gatilho
Este token pode ser adicionado imediatamente à configuração geral de variáveis de um grupo de projetos.
Vá para o grupo -> Configurações -> CI/CD -> Variáveis e adicione uma variávelDEPLOY_TOKENcom token de gatilho no valor.
GitLab RunnerName
Esta seção descreve a configuração para execução de tarefas na implantação usando o executor nativo (específico) e público (compartilhado).
Corredor Específico
Eu uso meus próprios corredores porque antes de tudo é conveniente, rápido e barato.
Para runner eu recomendo Linux VDS com 1 CPU, 2 GB de RAM, 20 GB de HDD. Preço de emissão ~ 3000₽ por ano.
Meu corredor
Para o corredor usei CPU VDS 4, 4 GB de RAM e SSD de 50 GB. Custou ~11000₽ e nunca me arrependi.
Tenho um total de 7 máquinas. 5 em Aruba e 2 em Ihor.
Então, temos um corredor. Agora vamos configurá-lo.
Vamos para a máquina via SSH e instalamos java, git, maven, gnupg2.
Instalando o gitlab runner
- Crie um novo grupo
runnersudo groupadd runner - Crie um diretório para o cache maven e atribua direitos de grupo
runner
Você pode pular este ponto se não planeja executar vários executores em uma máquina.mkdir -p /usr/cache/.m2/repository chown -R :runner /usr/cache chmod -R 770 /usr/cache - Crie um usuário
gitlab-deployere adicione ao gruporunneruseradd -m -d /home/gitlab-deployer gitlab-deployer usermod -a -G runner gitlab-deployer - Adicionar ao arquivo
/etc/ssh/sshd_configpróxima linhaAllowUsers root@* [email protected] - Reinício
sshdsystemctl restart sshd - Defina uma senha para o usuário
gitlab-deployer(pode ser simples, já que existe uma restrição para localhost)passwd gitlab-deployer - Instale o 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 - Vá para gitlab.com -> deploy-project -> Configurações -> CI/CD -> Corredores -> Corredores Específicos e copie o token de registro
Ecrã
- Cadastrando o corredor
gitlab-runner register --config /etc/gitlab-runner/gitlab-deployer-config.toml
processo
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!- Verifique se o corredor está registrado. Vá para gitlab.com -> deploy-project -> Configurações -> CI/CD -> Corredores -> Corredores Específicos -> Corredores ativados para este projeto
Ecrã
- Adicionar separar serviço
/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 - Iniciamos o serviço.
systemctl enable gitlab-deployer.service systemctl start gitlab-deployer.service systemctl status gitlab-deployer.service - Verifique se o corredor está funcionando.
Exemplo
Geração de chave GPG
-
Da mesma máquina vamos via ssh sob o usuário
gitlab-deployer(isso é importante para a geração de chaves GPG)ssh [email protected] -
Geramos uma chave respondendo a perguntas. Usei meu próprio nome e e-mail.
Certifique-se de especificar a senha da chave. Os artefatos serão assinados com esta chave.gpg --gen-key -
Verificar
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 -
Fazendo upload de nossa chave pública para o servidor de chaves
gpg --keyserver keys.gnupg.net --send-key 00000000 gpg: sending key 00000000 to hkp server keys.gnupg.net
Configuração do Maven
- Nós vamos sob o usuário
gitlab-deployersu gitlab-deployer - Crie um diretório maven repositório e link com o cache (não se engane)
Esta etapa pode ser ignorada se você não planeja executar vários executores na mesma máquina.mkdir -p ~/.m2/repository ln -s /usr/cache/.m2/repository /home/gitlab-deployer/.m2/repository - Crie uma chave mestra
mvn --encrypt-master-password password {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Crie o arquivo ~/.m2/settings-security.xml
<settingsSecurity> <master>{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}</master> </settingsSecurity> - Criptografando a senha da conta Sonatype
mvn --encrypt-password SONATYPE_PASSWORD {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J} - Crie o arquivo ~/.m2/settings.xml
<settings> <profiles> <profile> <id>env</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <gpg.passphrase>GPG_SECRET_KEY_PASSPHRASE</gpg.passphrase> </properties> </profile> </profiles> <servers> <server> <id>sonatype</id> <username>SONATYPE_USERNAME</username> <password>{98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}</password> </server> </servers> </settings>
onde
GPG_SECRET_KEY_PASSPHRASE - Senha da chave GPG
SONATYPE_USERNAME - login da conta sonatype
Isso conclui a configuração do corredor, você pode prosseguir para a seção
Corredor Compartilhado
Geração de chave GPG
-
Primeiro de tudo, você precisa criar uma chave GPG. Para fazer isso, instale o gnupg.
yum install -y gnupg -
Geramos uma chave respondendo a perguntas. Usei meu próprio nome e e-mail. Certifique-se de especificar a senha da chave.
gpg --gen-key -
Recuperar informações importantes
gpg --list-keys -a pub rsa3072 2019-04-24 [SC] [expires: 2021-04-23] 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 uid [ultimate] tttemp <[email protected]> sub rsa3072 2019-04-24 [E] [expires: none] -
Fazendo upload de nossa chave pública para o servidor de chaves
gpg --keyserver keys.gnupg.net --send-key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 gpg: sending key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 to hkp server keys.gnupg.net -
Obtendo uma chave privada
gpg --export-secret-keys --armor 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 -----BEGIN PGP PRIVATE KEY BLOCK----- lQWGBFzAqp8BDADN41CPwJ/gQwiKEbyA902DKw/WSB1AvZQvV/ZFV77xGeG4K7k5 ... =2Wd2 -----END PGP PRIVATE KEY BLOCK----- -
Vá para configurações do projeto -> Configurações -> CI/CD -> Variáveis e salve a chave privada em uma variável
GPG_SECRET_KEY
Configuração do Maven
- Crie uma chave mestra
mvn --encrypt-master-password password {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=} - Vá em configurações do projeto -> Configurações -> CI/CD -> Variáveis e salve em uma variável
SETTINGS_SECURITY_XMLas seguintes linhas:<settingsSecurity> <master>{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}</master> </settingsSecurity> - Criptografando a senha da conta Sonatype
mvn --encrypt-password SONATYPE_PASSWORD {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J} - Vá em configurações do projeto -> Configurações -> CI/CD -> Variáveis e salve em uma variável
SETTINGS_XMLas seguintes linhas:<settings> <profiles> <profile> <id>env</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <gpg.passphrase>GPG_SECRET_KEY_PASSPHRASE</gpg.passphrase> </properties> </profile> </profiles> <servers> <server> <id>sonatype</id> <username>sonatype_username</username> <password>{98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}</password> </server> </servers> </settings>
onde
GPG_SECRET_KEY_PASSPHRASE - Senha da chave GPG
SONATYPE_USERNAME - login da conta sonatype
Implantar imagem do Docker
-
Criamos um Dockerfile bastante simples para executar tarefas de implantação com a versão desejada do Java. Abaixo está um exemplo para alpino.
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/ -
Construindo um contêiner para seu projeto
docker build -t registry.gitlab.com/group/deploy . -
Autenticamos e carregamos o contêiner no registro.
docker login -u USER -p PASSWORD registry.gitlab.com docker push registry.gitlab.com/group/deploy
CI do GitLab
Implantar projeto
Adicione o arquivo .gitlab-ci.yml à raiz do projeto de implantação
O script apresenta duas tarefas de implantação mutuamente exclusivas. Corredor Específico ou Corredor Compartilhado respectivamente.
.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
Projeto Java
Em projetos Java que devem ser carregados em repositórios públicos, você precisa adicionar 2 etapas para baixar as versões Release e Snapshot.
.gitlab-ci.yml
stages:
- build
- test
- verify
- deploy
<...>
Release:
extends: .trigger_deploy
# Запускать задачу только пo тегу.
only:
- tags
Snapshot:
extends: .trigger_deploy
# Запускаем задачу на публикацию SNAPSHOT версии вручную
when: manual
# Не запускать задачу, если проставлен тег.
except:
- tags
.trigger_deploy:
stage: deploy
variables:
# Отключаем клонирование текущего проекта
GIT_STRATEGY: none
# Ссылка на триггер deploy-задачи
URL: "https://gitlab.com/api/v4/projects/<deploy project ID>/trigger/pipeline"
# Переменные deploy-задачи
POST_DATA: "
token=${DEPLOY_TOKEN}&
ref=master&
variables[DEPLOY]=${DEPLOY}&
variables[DEPLOY_CI_REPOSITORY_URL]=${CI_REPOSITORY_URL}&
variables[DEPLOY_CI_PROJECT_NAME]=${CI_PROJECT_NAME}&
variables[DEPLOY_CI_COMMIT_SHA]=${CI_COMMIT_SHA}&
variables[DEPLOY_CI_COMMIT_TAG]=${CI_COMMIT_TAG}
"
script:
# Не использую cURL, так как с флагами --fail --show-error
# он не выводит тело ответа, если HTTP код 400 и более
- wget --content-on-error -qO- ${URL} --post-data ${POST_DATA}Nesta solução, fui um pouco mais longe e decidi usar um modelo de CI para projetos java.
Mais detalhes
Eu criei um projeto separado em que ele colocou o modelo de CI para projetos Java .
comum.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
Como resultado, nos próprios projetos Java, .gitlab-ci.yml parece muito compacto e não detalhado
.gitlab-ci.yml
include: https://gitlab.com/TouchBIT/gitlab-ci/raw/master/common.yml
Shields4J:
extends: .build_java_project
Sphinx doc:
extends: .build_sphinx_doc
variables:
DOCKERFILE: .docs/Dockerfile
Sonar review:
extends: .sonar_review
dependencies:
- Shields4J
Release:
extends: .trigger_release_deploy
Snapshot:
extends: .trigger_snapshot_deploy
configuração pom.xml
Este tópico é descrito detalhadamente. в , então descreverei algumas das nuances do uso de plug-ins. Também descreverei como você pode usar de maneira fácil e descontraída nexus-staging-maven-pluginse você não quiser ou não puder usar org.sonatype.oss:oss-parent como pai do seu projeto.
plug-in de instalação do maven
Instala módulos no repositório local.
Muito útil para verificação local de soluções em outros projetos, bem como checksum.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<executions>
<execution>
<id>install-project</id>
<!-- Если у вас многомодульный проект с деплоем родительского помика -->
<phase>install</phase>
<!-- Явно указываем файлы для локальной установки -->
<configuration>
<file>target/${project.artifactId}-${project.version}.jar</file>
```target/${project.artifactId}-${project.version}-sources.jar</sources>
<pomFile>dependency-reduced-pom.xml</pomFile>
<!-- Принудительное обновление метаданных проекта -->
<updateReleaseInfo>true</updateReleaseInfo>
<!-- Контрольные суммы для проверки целостности -->
<createChecksum>true</createChecksum>
</configuration>
</execution>
</executions>
</plugin>
plugin-maven-javadoc
Gerando javadoc para o projeto.
<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>Se você possui um módulo que não contém java (por exemplo, apenas recursos)
Ou você não quer gerar javadoc em princípio, então para ajudar maven-jar-plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<executions>
<execution>
<id>empty-javadoc-jar</id>
<phase>generate-resources</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<classifier>javadoc</classifier>
<classesDirectory>${basedir}/javadoc</classesDirectory>
</configuration>
</execution>
</executions>
</plugin>
plugin maven-gpg
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<executions>
<execution>
<id>sign-artifacts</id>
<!-- Сборка будет падать, если отсутствует GPG ключ -->
<!-- Подписываем артефакты только на фазе deploy -->
<phase>deploy</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
</plugin>
plug-in nexus-staging-maven
Configuração:
<project>
<!-- ... -->
<build>
<plugins>
<!-- ... -->
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
</plugin>
</plugins>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<serverId>sonatype</serverId>
<nexusUrl>https://oss.sonatype.org/</nexusUrl>
<!-- Обновляем метаданные, чтобы пометить артефакт как release -->
<!-- Не влияет на snapshot версии -->
<updateReleaseInfo>true</updateReleaseInfo>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<!-- Отключаем плагин -->
<skip>true</skip>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
<distributionManagement>
<snapshotRepository>
<id>sonatype</id>
<name>Nexus Snapshot Repository</name>
<url>https://oss.sonatype.org/content/repositories/snapshots/</url>
</snapshotRepository>
<repository>
<id>sonatype</id>
<name>Nexus Release Repository</name>
<url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
</repository>
</distributionManagement>
</project>Se você possui um projeto com vários módulos e não precisa fazer upload de um módulo específico para o repositório, será necessário adicioná-lo ao pom.xml deste módulo nexus-staging-maven-plugin com bandeira skipNexusStagingDeployMojo
<build>
<plugins>
<plugin>
<groupId>org.sonatype.plugins</groupId>
<artifactId>nexus-staging-maven-plugin</artifactId>
<configuration>
<skipNexusStagingDeployMojo>true</skipNexusStagingDeployMojo>
</configuration>
</plugin>
</plugins>
</build>Após o upload, as versões de snapshot/lançamento estarão disponíveis em
<repositories>
<repository>
<id>SonatypeNexus</id>
<url>https://oss.sonatype.org/content/groups/staging/</url>
<!-- Не надо указывать флаги snapshot/release для репозитория -->
</repository>
</repositories>Mais vantagens
- Uma lista muito rica de objetivos para trabalhar com o repositório Nexus (
mvn help:describe -Dplugin=org.sonatype.plugins:nexus-staging-maven-plugin). - Verificação automática de liberação para upload para maven central
resultado
Publicando uma versão SNAPSHOT
Ao construir um projeto, é possível iniciar manualmente uma tarefa para baixar a versão SNAPSHOT para o Nexus
Quando esta tarefa é iniciada, a tarefa correspondente no projeto de implantação é acionada ().
tronco cortado
Running with gitlab-runner 11.10.0 (3001a600)
on Deploy runner JSKWyxUw
Using Shell executor...
Running on ih1174328.vds.myihor.ru...
Skipping Git repository setup
Skipping Git checkout
Skipping Git submodules setup
$ rm -rf .* *
$ git config --global credential.helper store
$ echo "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.com" >> ~/.git-credentials
$ git clone ${DEPLOY_CI_REPOSITORY_URL} .
Cloning into 'shields4j'...
$ git checkout ${DEPLOY_CI_COMMIT_SHA}
Note: checking out '850f86aa317194395c5387790da1350e437125a7'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b new_branch_name
HEAD is now at 850f86a... skip deploy test-core
$ for pom in $(find . -name pom.xml); do # collapsed multi-line command
$ if [[ "${DEPLOY_CI_COMMIT_TAG}" != "" ]]; then # collapsed multi-line command
[INFO] Scanning for projects...
[INFO] Inspecting build with total of 4 modules...
[INFO] Installing Nexus Staging features:
[INFO] ... total of 4 executions of maven-deploy-plugin replaced with nexus-staging-maven-plugin
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] Shields4J [pom]
[INFO] test-core [jar]
[INFO] Shields4J client [jar]
[INFO] TestNG listener [jar]
[INFO]
[INFO] --------------< org.touchbit.shields4j:shields4j-parent >---------------
[INFO] Building Shields4J 1.0.0 [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
[INFO]
[INFO] --- versions-maven-plugin:2.5:set (default-cli) @ shields4j-parent ---
[INFO] Searching for local aggregator root...
[INFO] Local aggregation root: /home/gitlab-deployer/JSKWyxUw/0/TouchBIT/deploy/shields4j
[INFO] Processing change of org.touchbit.shields4j:shields4j-parent:1.0.0 -> 1.0.0-SNAPSHOT
[INFO] Processing org.touchbit.shields4j:shields4j-parent
[INFO] Updating project org.touchbit.shields4j:shields4j-parent
[INFO] from version 1.0.0 to 1.0.0-SNAPSHOT
[INFO]
[INFO] Processing org.touchbit.shields4j:client
[INFO] Updating parent org.touchbit.shields4j:shields4j-parent
[INFO] from version 1.0.0 to 1.0.0-SNAPSHOT
[INFO] Updating dependency org.touchbit.shields4j:test-core
[INFO] from version 1.0.0 to 1.0.0-SNAPSHOT
[INFO]
[INFO] Processing org.touchbit.shields4j:test-core
[INFO] Updating parent org.touchbit.shields4j:shields4j-parent
[INFO] from version 1.0.0 to 1.0.0-SNAPSHOT
[INFO]
[INFO] Processing org.touchbit.shields4j:testng
[INFO] Updating parent org.touchbit.shields4j:shields4j-parent
[INFO] from version 1.0.0 to 1.0.0-SNAPSHOT
[INFO] Updating dependency org.touchbit.shields4j:client
[INFO] from version 1.0.0 to 1.0.0-SNAPSHOT
[INFO] Updating dependency org.touchbit.shields4j:test-core
[INFO] from version 1.0.0 to 1.0.0-SNAPSHOT
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Shields4J 1.0.0 .................................... SUCCESS [ 0.992 s]
[INFO] test-core .......................................... SKIPPED
[INFO] Shields4J client ................................... SKIPPED
[INFO] TestNG listener 1.0.0 .............................. SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.483 s
[INFO] Finished at: 2019-04-21T02:40:42+03:00
[INFO] ------------------------------------------------------------------------
$ mvn clean deploy -DskipTests=${SKIP_TESTS}
[INFO] Scanning for projects...
[INFO] Inspecting build with total of 4 modules...
[INFO] Installing Nexus Staging features:
[INFO] ... total of 4 executions of maven-deploy-plugin replaced with nexus-staging-maven-plugin
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO]
[INFO] Shields4J [pom]
[INFO] test-core [jar]
[INFO] Shields4J client [jar]
[INFO] TestNG listener [jar]
[INFO]
[INFO] --------------< org.touchbit.shields4j:shields4j-parent >---------------
[INFO] Building Shields4J 1.0.0-SNAPSHOT [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
...
DELETED
...
[INFO] * Bulk deploy of locally gathered snapshot artifacts finished.
[INFO] Remote deploy finished with success.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Shields4J 1.0.0-SNAPSHOT ........................... SUCCESS [ 2.375 s]
[INFO] test-core .......................................... SUCCESS [ 3.929 s]
[INFO] Shields4J client ................................... SUCCESS [ 3.815 s]
[INFO] TestNG listener 1.0.0-SNAPSHOT ..................... SUCCESS [ 36.134 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 47.629 s
[INFO] Finished at: 2019-04-21T02:41:32+03:00
[INFO] ------------------------------------------------------------------------Como resultado, a versão do Nexus é carregada .
Todas as versões de snapshot podem ser removidas do repositório no site sob sua conta.
Publicação da versão de lançamento
Quando a tag é definida, a tarefa correspondente no projeto de implantação é automaticamente acionada para fazer upload da versão de lançamento para o Nexus ().
A melhor parte é que a liberação próxima é acionada automaticamente no nexo.
[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] ------------------------------------------------------------------------E se algo der errado, a tarefa irá falhar
[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] ------------------------------------------------------------------------Como resultado, ficamos com apenas uma escolha. Ou exclua esta versão ou publique.
Após o lançamento, depois de algum tempo, os artefatos estarão em
oftop
Foi uma revelação para mim que o maven indexa outros repositórios públicos.
Tive que fazer upload do robots.txt porque ele indexava meu antigo repositório.
Conclusão
O que nós temos
- Um projeto de implantação separado no qual é possível implementar diversas tarefas de CI para fazer upload de artefatos para repositórios públicos para diversas linguagens de desenvolvimento.
- O projeto de implantação é isolado de interferências externas e só pode ser modificado por usuários com funções de Proprietário e Mantenedor.
- Um executor específico separado com um cache “quente” para executar apenas tarefas de implantação.
- Publicação de versões de snapshot/lançamento em um repositório público.
- Verificação automática da versão de lançamento quanto à disponibilidade para publicação no maven central.
- Proteção contra publicação automática de versões “brutas” no maven central.
- Crie e publique versões de snapshot “com um clique”.
- Repositório único para obter versões de snapshot/lançamento.
- Pipeline geral para construção/teste/publicação de um projeto java.
Configurar o GitLab CI não é um tópico tão complicado quanto parece à primeira vista. Basta configurar o CI pronto para uso algumas vezes e agora você está longe de ser um amador nesse assunto. Além disso, a documentação do GitLab é muito redundante. Não tenha medo de dar o primeiro passo. A estrada aparece sob os passos de quem anda (não me lembro quem disse isso :)
Ficarei feliz em receber feedback.
No próximo artigo, mostrarei como configurar o GitLab CI para executar tarefas de teste de integração de forma competitiva (executando serviços de teste com docker-compose) se você tiver apenas um executor de shell.
Fonte: habr.com