Configurando o GitLab CI para carregar um projeto java no maven central

Este artigo destina-se a desenvolvedores de java que precisam publicar rapidamente seus produtos no tipo de sonata e / ou repositórios centrais do maven usando o GitLab. Neste artigo, falarei sobre a configuração do gitlab-runner, gitlab-ci e maven-plugin para solucionar esse problema.

Pré-requisitos:

Armazenamento seguro de chaves mvn e GPG.
Execução segura de tarefas de IC público.
Faça o upload de artefatos (release / snapshot) para repositórios públicos.
Verifique automaticamente as versões para publicação na maven central.
Uma solução geral para fazer upload de artefatos no repositório para vários projetos.
Simplicidade e usabilidade.

Conteúdo

Informação geral

Uma descrição detalhada do mecanismo para publicação de artefatos no Maven Central por meio do Serviço de Hospedagem de Repositório Sonatype OSS já foi descrita neste artigo pelo Googolplex ; portanto, irei me referir a este artigo nos lugares certos.
Efetuamos um pré-registro no Sonatype JIRA e iniciamos um ticket para abrir o repositório (para obter mais detalhes, leia a seção Criando um Ticket para o Sonatype JIRA ). Após abrir o repositório, o par de login / senha do JIRA (a seguir conta do Sonatype) será usado para fazer upload de artefatos no Sonatype nexus.
O processo para gerar uma chave GPG é descrito muito secamente abaixo. Consulte Configurando o GnuPG para assinar artefatos para obter mais informações.
Se você usar o console do Linux para gerar a chave GPG (gnupg / gnupg2), precisará instalar o rng-tools para gerar entropia. Caso contrário, a geração de chaves poderá demorar muito tempo.
Serviços para armazenar chaves GPG públicas

Para o conteúdo

Configurando um projeto de implantação no GitLab

Antes de tudo, é necessário criar e configurar um projeto no qual o pipeline será armazenado para implantar artefatos. Chamei meu projeto de simples e direto - implantar
Depois de criar o repositório, você deve 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 a única regra com curinga *, com o direito de enviar e mesclar apenas para usuários com a função de mantenedores. Esta regra funcionará para todos os usuários deste projeto, bem como para o grupo no qual esse projeto é membro.
Se houver vários mantenedores, a melhor solução seria limitar o acesso ao projeto em princípio.
Vá para o projeto -> Configurações -> Geral -> Visibilidade, recursos do projeto, permissões e defina a visibilidade do Projeto como Privado .
Eu tenho um projeto em domínio público, pois uso meu próprio GitLab Runner e só tenho acesso para alterar o repositório. Bem, na verdade, não é do meu interesse divulgar informações privadas em registros públicos de canais.
Regras mais rígidas para alterar o repositório
Vá para o projeto -> Configurações -> Repositório -> Regras de envio e defina os sinalizadores Restrição de committer, Verifique se o autor é um usuário do GitLab. Também recomendo que você configure a assinatura das confirmações e defina o sinalizador Rejeitar confirmações não assinadas.
Em seguida, você precisa configurar o gatilho para executar tarefas
Vá para o projeto -> Configurações -> CI / CD -> Gatilhos de pipeline e crie um novo token de gatilho
Esse token pode ser adicionado imediatamente à configuração geral de variáveis para um grupo de projetos.
Vá para o grupo -> Configurações -> CI / CD -> Variáveis e adicione a variável DEPLOY_TOKEN com token de gatilho no valor.

Para o conteúdo

Corredor do Gitlab

Esta seção descreve a configuração para iniciar tarefas na implantação usando seu próprio corredor (Específico) e público (Compartilhado).

Corredor específico

Eu uso meus próprios corredores, como antes de tudo é conveniente, rápido, barato.
Para o corredor, eu recomendo o Linux VDS com 1 CPU, 2 GB de RAM, 20 GB de disco rígido. O preço de emissão é de ~ 3000₽ por ano.

Meu corredor

Para o corredor, peguei VDS 4 CPU, 4 GB RAM, 50 GB SSD. Custou ~ 11.000 rublos e nunca se arrependeu.
Eu tenho um total de 7 carros. 5 em Aruba e 2 em Ihor.

Então, nós temos um corredor. Agora vamos configurá-lo.
Vamos para a máquina no SSH e instalamos java, git, maven, gnupg2.

Para o conteúdo

Instale o gitlab runner

Crie um novo grupo de runner
```
 sudo groupadd runner 
```
Crie um diretório para o cache do maven e anexe os direitos do grupo de runner
Você pode pular este item se não planeja executar vários corredores na mesma máquina.
```
 mkdir -p /usr/cache/.m2/repository chown -R :runner /usr/cache chmod -R 770 /usr/cache 
```

Crie o gitlab-deployer do gitlab-deployer e adicione o runner ao grupo

 useradd -m -d /home/gitlab-deployer gitlab-deployer usermod -a -G runner gitlab-deployer

Adicione a seguinte linha ao arquivo /etc/ssh/sshd_config
```
 AllowUsers root@* gitlab-deployer@127.0.0.1 
```
Reiniciar sshd
```
 systemctl restart sshd 
```
Definimos a senha do usuário do gitlab-deployer (pode ser simples, pois a restrição para o host local se aplica)
```
 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

Acesse gitlab.com -> deploy-project -> Configurações -> CI / CD -> Corredores -> Corredores específicos e copie o token de registro

Ecrã

Registrar corredor

 gitlab-runner register --config /etc/gitlab-runner/gitlab-deployer-config.toml

O 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 (eg 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ã

Adicione um serviço separado /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

Para o conteúdo

Geração de chave GPG

Na mesma máquina, gitlab-deployer o ssh sob o usuário gitlab-deployer (isso é importante para gerar uma chave GPG)
```
 ssh gitlab-deployer@127.0.0.1 
```
Geramos uma chave respondendo perguntas. Eu usei meu próprio nome e e-mail.
Certifique-se de especificar a senha da chave. Essa chave assinará artefatos.
```
 gpg --gen-key 
```

Verifique

 gpg --list-keys -a /home/gitlab-deployer/.gnupg/pubring.gpg ---------------------------------------- pub 4096R/00000000 2019-04-19 uid Petruha Petrov <pp@example.com> sub 4096R/11111111 2019-04-19

Carregando nossa chave pública no servidor de chaves

 gpg --keyserver keys.gnupg.net --send-key 00000000 gpg: sending key 00000000 to hkp server keys.gnupg.net

Para o conteúdo

Configuração do Maven

Vamos sob o usuário gitlab-deployer
```
 su gitlab-deployer 
```
Crie um repositório maven e vincule-o ao cache (não se engane)
Você pode pular este item se não planeja iniciar vários corredores 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>

Criptografamos 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 completa a configuração do corredor, você pode ir para a seção CI do GitLab

Para o conteúdo

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 perguntas. Eu usei meu próprio nome e e-mail. Certifique-se de especificar a senha da chave.
```
 gpg --gen-key 
```

Exibimos informações na tecla

 gpg --list-keys -a pub rsa3072 2019-04-24 [SC] [expires: 2021-04-23] 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 uid [ultimate] tttemp <temp@temp.temp> sub rsa3072 2019-04-24 [E] [expires: none]

Carregando nossa chave pública no servidor de chaves

 gpg --keyserver keys.gnupg.net --send-key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 gpg: sending key 2D0D1706366FC4AEF79669E24D09C55BBA3FD728 to hkp server keys.gnupg.net

Obter a 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 as configurações do projeto -> Configurações -> CI / CD -> Variáveis e salve a chave privada na variável GPG_SECRET_KEY

Para o conteúdo

Configuração do Maven

Crie uma chave mestra

 mvn --encrypt-master-password password {hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}

Vá para as configurações do projeto -> Configurações -> CI / CD -> Variáveis e salve as seguintes linhas na variável SETTINGS_SECURITY_XML :
```
 <settingsSecurity> <master>{hnkle5BJ9HUHUMP+CXfGBl8dScfFci/mpsur/73tR2I=}</master> </settingsSecurity> 
```

Criptografamos a senha da conta Sonatype

 mvn --encrypt-password SONATYPE_PASSWORD {98Wv5+u+Tn0HX2z5G/kR4R8Z0WBgcDBgi7d12S/un+SCU7uxzaZGGmJ8Cu9pAZ2J}

Vá para as configurações do projeto -> Configurações -> CI / CD -> Variáveis e salve as seguintes linhas na variável 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

Para o conteúdo

Implantar imagem de janela de encaixe

Crie um Dockerfile simples o suficiente para executar tarefas na implantação com a versão correta 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/

Coletamos o contêiner para o seu projeto

 docker build -t registry.gitlab.com/group/deploy .

Autentique e carregue o contêiner no registro.

 docker login -u USER -p PASSWORD registry.gitlab.com docker push registry.gitlab.com/group/deploy

Para o conteúdo

Gitlab ci

Implantar projeto

Inclua o arquivo .gitlab-ci.yml na raiz do projeto de implantação
O script apresenta duas tarefas mutuamente exclusivas na implantação. 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

Para o conteúdo

Projeto Java

Nos projetos java que deveriam 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 IC para projetos java.

Mais detalhes

Criei um projeto gitlab-ci separado no qual coloquei um modelo de IC para projetos java common.yml .

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

Como resultado, nos próprios projetos java, o .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

Para o conteúdo

Configuração Pom.xml

Este tópico é descrito em detalhes pelo Googolplex em Configurando o maven para assinatura automática e upload de artefatos em repositórios de captura instantânea e de teste , portanto, descreverei algumas das nuances do uso de plug-ins. Também descreverei com que facilidade e natural você pode usar o nexus-staging-maven-plugin se não quiser ou não puder usar org.sonatype.oss: oss-parent como pai do seu projeto.

maven-install-plugin

Instala módulos no repositório local.
Muito útil para verificação local de soluções em outros projetos, bem como uma soma de verificação.

 <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>

Para o conteúdo

maven-javadoc-plugin

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 deseja gerar o javadoc em princípio, então o maven-jar-plugin ajudará

 <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>

Para o conteúdo

maven-gpg-plugin

 <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>

Para o conteúdo

nexus-staging-maven-plugin

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 carregar um módulo específico no repositório, adicione nexus-staging-maven-plugin com o sinalizador skipNexusStagingDeployMojo ao pom.xml deste módulo

 <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 download, as versões de captura instantânea / liberação estão disponíveis no repositório de preparação.

 <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 ).
Verificar automaticamente a liberação quanto à capacidade de download no maven central

Para o conteúdo

Resultado

Publicar versão do INSTANTÂNEO

Ao criar um projeto, existe a possibilidade de iniciar manualmente uma tarefa para baixar a versão SNAPSHOT no nexus

Quando essa tarefa é iniciada, a tarefa correspondente no projeto de implantação é acionada ( exemplo ).

Log aparado

 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 1.0.0-SNAPSHOT é carregada no nexus.

Todas as versões de instantâneo podem ser excluídas do repositório em oss.sonatype.org em sua conta.

Para o conteúdo

Publicar versão de lançamento

Quando a tag é instalada, a tarefa correspondente no projeto de implantação é acionada automaticamente para baixar a versão do release no nexus ( exemplo ).

A melhor parte é que o lançamento próximo no nexus é acionado automaticamente.

 [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 certamente 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 &lt;a href=http://keys.gnupg.net:11371/&gt;http://keys.gnupg.net:11371/&lt;/a&gt;. 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] ------------------------------------------------------------------------

. .

,

, maven .
robots.txt, .

Para o conteúdo

Conclusão

deploy- CI .
Deploy- Owner Maintainer.
Specific Runner "" deploy .
snapshot/release .
release maven central.
"" maven central.
snapshot " ".
snapshot/release .
// java .

GitLab CI . CI " " , . GitLab . . ( :) ).

.

, GitLab CI ( docker-compose), shell .

Para o conteúdo

Source: https://habr.com/ru/post/pt449664/

All Articles