Действия GitHub Ошибка сборки Maven с ошибкой «относительного пути» после обновления динамической версии

Я работаю над проектом, в котором мы используем GitHub Actions для автоматизации процесса сборки Maven. Мы динамически устанавливаем номер версии в формате projectversion-runID-runNumber, например 8.1.0-9761957358-18. Мы включаем этот runID в версию сборки, чтобы рабочий процесс развертывания мог проанализировать его и загрузить артефакты из рабочего процесса сборки.

В нашем рабочем процессе сборки мы используем mvnversions:set для обновления версий. Однако команда завершается с ошибкой «относительного пути» специально для подмодулей, которые ссылаются на poms модуля как на родительских с помощью ../../pom.xml. Файлы pom этих модулей, которые ссылаются на родительский pom с помощью ../pom.xml, похоже, не имеют проблем. Вот подробности:

Сообщение об ошибке:

[ERROR] Child module ... of ... cannot be found in the workspace
[ERROR] The POM for ... is missing, no dependency information available
[FATAL] Non-resolvable parent POM for com.example.project.submodule: Could not find artifact com.example.project:module:pom:8.1.0-9761957358-18 in central (https://repo1.maven.org/maven2) and 'parent.relativePath' points at wrong local POM

Структура файла:

project-root/
│
├── pom.xml
├── module1/
│   ├── pom.xml
│   └── modules/
│       ├── submodule1/
│       │   └── pom.xml
│       ├── submodule2/
│       │   └── pom.xml

Шаги рабочего процесса:

name: Build and Publish

on:
  push:
    paths-ignore: ['.github/**']
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo
        uses: actions/checkout@v4

      - name: Set Up JDK 11
        uses: actions/setup-java@v4
        with:
          java-version: 11
          distribution: 'temurin'
          cache: maven

      - name: Set Version
        run: |
          mvn versions:set -DnewVersion=8.1.0-${{ github.run_id }}-${{ github.run_number }} -DgenerateBackupPoms=false

Я проверил, что файлы POM существуют в локальном репозитории, который, по моему мнению, является первым местом, куда смотрит Maven. Мы включаем runID в версию сборки, чтобы можно было проанализировать идентификатор запуска из тега, который мы создаем на его основе. Это позволяет GitHub развертывать артефакты загрузки рабочего процесса, созданные в ходе рабочего процесса сборки.

Примеры файлов POM:

Родительский POM (pom.xml):

<project xmlns = "http://maven.apache.org/POM/4.0.0" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example.project</groupId>
  <artifactId>parent-project</artifactId>
  <version>8.1.0</version>
  <packaging>pom</packaging>
  <modules>
    <module>module1</module>
  </modules>
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>
</project>
Module POM (module1/pom.xml):

<project xmlns = "http://maven.apache.org/POM/4.0.0" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <parent>
    <artifactId>parent-project</artifactId>
    <groupId>com.example.project</groupId>
    <version>8.1.0</version>
    <relativePath>../pom.xml</relativePath>
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example.project.module1</groupId>
  <artifactId>module1</artifactId>
  <packaging>pom</packaging>
  <modules>
    <module>modules/submodule1</module>
  </modules>
</project>
Submodule POM (module1/modules/submodule1/pom.xml):

<project xmlns = "http://maven.apache.org/POM/4.0.0" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://www.maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <parent>
    <artifactId>module1</artifactId>
    <groupId>com.example.project.module1</groupId>
    <version>8.1.0</version>
    <relativePath>../../pom.xml</relativePath>
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example.project.module1</groupId>
  <artifactId>submodule1</artifactId>
  <packaging>jar</packaging>
</project>

Вещи, которые я пробовал:

• Замена командыversions:set на mvn dependency:tree и столкнулся с той же ошибкой «относительного пути».
• Добавление rm -rf локального репозитория maven github action runner, в убедитесь, что кеш maven очищен, и это не помогло.
• Удаление runID из номеров версий сборки. Та же проблема.
• Индивидуальная установка всех помпов явно, с mvn install -N для каждого модуля. Никаких кубиков.
• Дважды проверил, что идентификаторы групп и артефактов, а также версии, перечисленные в родительские разделы соответствовали тому, что было в родительском pom.xml, на который ссылаются.
• Раньше этот рабочий процесс как-то выполнялся, но потом кто-то выполнил слияние. день, и все сборки начали терпеть неудачу. Мне интересно, если это возможно, имел доступ к чему-то кэшированному, но не знал как.
• Создание кода из коммита перед слиянием привел к той же ошибке.
• Сборка кода локально на виртуальной машине Windows 10 с использованием сценария оболочки, который использует тот же репозиторий и файлы pom, работает.
• Мы воспроизвели ошибку, защитив один из pom-файлов от записи, установив версии, затем сняв защиту от записи и попытавшись установить их снова. Возможно, это каким-то образом происходит на ранних этапах сборки, но не знаю, как устранить неполадки, если это происходит.

Будем очень признательны за любые идеи о том, как решить эту проблему!