Как установить maven для gitlab runner в оболочке докера - PullRequest
0 голосов
/ 10 мая 2019

(Обратите внимание, что я новичок во всех Docker и CI в целом)

Я пытаюсь настроить простую CI-среду с GitLab.Я использую локальный GitLab Runner, который настроен для сборки и тестирования в Docker.При регистрации бегуна я выбрал опцию «shell».Эта установка прошла успешно.

После нажатия на мой код я получил электронное письмо с надписью «сборка не удалась».В журнале сборки я нашел следующее:

  on desktop-docker-runner cDD_yf4V
Using Shell executor...
Running on b567d1ba4654...
DEPRECATION: this GitLab server doesn't support refspecs, gitlab-runner 12.0 will no longer work with this version of GitLab
Fetching changes...
Checking out fd20ca86 as dev...
Skipping object checkout, Git LFS is not installed.

Skipping Git submodules setup
Checking cache for default...
Runtime platform                                    arch=amd64 os=linux pid=722 revision=1f513601 version=11.10.1
No URL provided, cache will not be downloaded from shared cache server. Instead a local version of cache will be extracted. 
Successfully extracted cache
$ mvn $MAVEN_CLI_OPTS test-compile
bash: line 74: mvn: command not found
ERROR: Job failed: exit status 1

Как добавить Maven для решения этой проблемы?

(РЕДАКТИРОВАТЬ: добавлен файл gitlab-ci.yml)

# Build JAVA applications using Apache Maven (http://maven.apache.org)
# For docker image tags see https://hub.docker.com/_/maven/
#
# For general lifecycle information see https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
#
# This template will build and test your projects as well as create the documentation.
#
# * Caches downloaded dependencies and plugins between invocation.
# * Verify but don't deploy merge requests.
# * Deploy built artifacts from master branch only.
# * Shows how to use multiple jobs in test stage for verifying functionality
#   with multiple JDKs.
# * Uses site:stage to collect the documentation for multi-module projects.
# * Publishes the documentation for `master` branch.

variables:
  # This will suppress any download for dependencies and plugins or upload messages which would clutter the console log.
  # `showDateTime` will show the passed time in milliseconds. You need to specify `--batch-mode` to make this work.
  MAVEN_OPTS: "-Dhttps.protocols=TLSv1.2 -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=WARN -Dorg.slf4j.simpleLogger.showDateTime=true -Djava.awt.headless=true"
  # As of Maven 3.3.0 instead of this you may define these options in `.mvn/maven.config` so the same config is used
  # when running from the command line.
  # `installAtEnd` and `deployAtEnd` are only effective with recent version of the corresponding plugins.
  MAVEN_CLI_OPTS: "--batch-mode --errors --fail-at-end --show-version -DinstallAtEnd=true -DdeployAtEnd=true"

# Cache downloaded dependencies and plugins between builds.
# To keep cache across branches add 'key: "$CI_JOB_NAME"'
cache:
  paths:
    - .m2/repository

# This will only validate and compile stuff and run e.g. maven-enforcer-plugin.
# Because some enforcer rules might check dependency convergence and class duplications
# we use `test-compile` here instead of `validate`, so the correct classpath is picked up.
.validate: &validate
  stage: build
  script:
    - 'mvn $MAVEN_CLI_OPTS test-compile'

# For merge requests do not `deploy` but only run `verify`.
# See https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
.verify: &verify
  stage: test
  script:
    - 'mvn $MAVEN_CLI_OPTS verify site site:stage'
  except:
    - master

# Validate merge requests using JDK7
validate:jdk7:
  <<: *validate
  image: maven:3.3.9-jdk-7

# Validate merge requests using JDK8
validate:jdk8:
  <<: *validate
  image: maven:3.3.9-jdk-8

# Verify merge requests using JDK7
verify:jdk7:
  <<: *verify
  image: maven:3.3.9-jdk-7

# Verify merge requests using JDK8
verify:jdk8:
  <<: *verify
  image: maven:3.3.9-jdk-8

# For `master` branch run `mvn deploy` automatically.
# Here you need to decide whether you want to use JDK7 or 8.
# To get this working you need to define a volume while configuring your gitlab-ci-multi-runner.
# Mount your `settings.xml` as `/root/.m2/settings.xml` which holds your secrets.
# See https://maven.apache.org/settings.html
deploy:jdk8:
  # Use stage test here, so the pages job may later pickup the created site.
  stage: test
  script:
    - 'mvn $MAVEN_CLI_OPTS deploy site site:stage'
  only:
    - master
  # Archive up the built documentation site.
  artifacts:
    paths:
    - target/staging
  image: maven:3.3.9-jdk-8

pages:
  image: busybox:latest
  stage: deploy
  script:
    # Because Maven appends the artifactId automatically to the staging path if you did define a parent pom,
    # you might need to use `mv target/staging/YOUR_ARTIFACT_ID public` instead.
    - mv target/staging public
  dependencies:
    - deploy:jdk8
  artifacts:
    paths:
    - public
  only:
    - master

1 Ответ

0 голосов
/ 10 мая 2019

Я использую локальный GitLab Runner, который настроен для сборки и тестирования в Docker.При регистрации бегуна я выбрал опцию «shell»

Из его звуков вы неправильно зарегистрировали gitlab-runner для выбранного вами режима.Вы сказали, что хотите использовать бегун для сборки и тестирования в Docker, однако вы зарегистрировали бегун в режиме shell.

Чтобы использовать бегун в Docker, следуйте инструкциям, изложенным в документации .Обязательно установите исполнитель бегуна на Docker при регистрации .

В идеале вы также должны удалить созданного вами бегуна оболочки.

Еслиу вас есть проблемы с регистрацией бегуна, см. этот ответ , что также может помочь в настройке вашей среды.

...