Сборка Maven как артефакт GitLab игнорируется следующими заданиями - PullRequest
1 голос
/ 06 августа 2020

У меня есть конвейер, в котором первые 2 этапа: один для сборки и один для модульных тестов в проекте Maven.

Два этапа могут можно суммировать следующими командами:

  • [build] mvn -s ci/settings.xml test-compile
  • [unit_tests] mvn -s ci/settings.xml verify

При запуске на локальном компьютере , первый выводит:

[INFO] Changes detected - recompiling the module!
[INFO] Compiling 133 source files to <mydir>

, а второй, учитывая, что проект уже построен, печатает:

[INFO] Nothing to compile - all classes are up to date

, и это ожидаемое поведение и в GitLab.

Однако в GitLab происходит то, что этап модульных тестов печатает то же самое, что и этап сборки, а это означает, что он неправильно использует артефакт, который я экспортировал в предыдущий этап.

Это задание build :

build:
  stage: build
  image: maven:3.6-jdk-11
  script:
    - 'mvn -s ci/settings.xml test-compile'
  except:
    - tags
  artifacts:
    paths:
      - target/

Это задание заканчивается следующим журналом:

Uploading artifacts...
target/: found 226 matching files and directories  
Uploading artifacts as "archive" to coordinator... ok  id=1964 responseStatus=201 Created token=qwYzjEeM

Это означает, что папка target была загружена правильно.

Это модульные тесты задание: * 104 5 *

junit:
  stage: unit_tests
  script:    
    - 'mvn -s ci/settings.xml verify'
  artifacts:
    reports:
      junit:
        - target/surefire-reports/TEST-*.xml

Это задание начинается со следующего журнала:

Downloading artifacts for build (1964)...
Downloading artifacts from coordinator... ok        id=1964 responseStatus=200 OK token=qwYzjEeM

, что означает, что папка target была получена правильно (я также добавил ls -la target, чтобы узнать, файлы были там, и они казались правильными).

Учитывая, что артефакты кажутся загруженными / загруженными правильно, почему задание unit tests восстанавливает весь проект?

1 Ответ

0 голосов
/ 20 августа 2020

Итак, в конечном итоге проблема вызвана как тем, как GitLab восстанавливает артефакты, так и тем, как git clone работает.

Обычно GitLab сохранит артефакты отметка времени последнего изменения, а git clone не будет.

Это приводит к следующему сценарию:

  1. git clone выполняется, и теперь все файлы в src каталог имеет текущую метку времени
  2. GitLab извлекает архив артефактов и сохраняет временные метки, поэтому теперь файлы в каталоге target имеют метку времени, которая была у них в предыдущем задании CI
  3. Это означает, что файлы в каталоге target будут выглядеть старше, чем файлы в каталоге src, и это вызовет полную перекомпиляцию в Maven

О проблеме было сообщено на GitLab , и его можно отследить здесь .

Временное решение - вручную создать архив артефактов и вручную извлечь его, когда начнется другое задание.

Это это образец конвейера th at используется в качестве обходного пути (опция -DD - это тот вариант, который не сохраняет отметки времени при извлечении, и именно поэтому этот обходной путь действительно работает):

.prepare-build-artifact: &prepare-build-artifact |
  apt update && apt install -y zip
  zip -r -q target.zip target/

.extract-build-artifact: &extract-build-artifact |
  unzip -DD -q target.zip

build:
  stage: build
  image: maven:3.6-jdk-11
  script:
    - 'mvn test-compile'
    - *prepare-build-artifact
  except:
    - tags
  artifacts:
    paths:
      - target.zip

junit:
  stage: unit_tests
  script:
    - *extract-build-artifact
    - 'mvn verify'
  artifacts:
    reports:
      junit:
        - target/surefire-reports/TEST-*.xml
...