GitHub Actions Maven Build Failing with "relative path" Error After Dynamic Version Update

I'm working on a project where we use GitHub Actions to automate our Maven build process. We dynamically set the version number in the format projectversion-runID-runNumber, like 8.1.0-9761957358-18. We include that runID in the build version so the deploy workflow can parse it out and download artifacts from the build workflow.

In our build workflow, we use mvn versions:set to update the versions. However, the command is failing with a "relative path" error specifically for the submodules which refer to the module poms as parents with ../../pom.xml. The pom files of those modules, which refer to the parent pom with ../pom.xml, seem to have no problem. Here are the details:

Error Message:

[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

File Structure:

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

Workflow Steps:

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

I've verified that the POM files do exist in the local repository, which I believe is the first place Maven looks. We incorporate the runID into the build version so we can parse out the run ID from the tag we create from it. This lets the GitHub deploy workflow download artifacts created from the build workflow.

POM File Examples:

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

Things I've tried:

• Replacing the versions:set command with mvn dependency:tree and encountered the same "relative path" error.
• Adding an rm -rf of the github action runner's local maven repo, to make sure the maven cache was cleared, and it didn't help.
• Taking out the runID in the build version numbers. Same problem.
• Individually installing all the poms explicitly, with mvn install -N for each module. No dice.
• Doublechecked that the groupIds and artifactIds, and versions listed in the parent sections matched what was in the parent pom.xml referred to.
• This workflow did run somehow before, but then someone did a merge one day and all the builds started failing this way. I'm wondering if it was maybe accessing something cached, but not sure how.
• Building the code from the commit before that merge still resulted in the same error.
• Building the code locally in a Windows 10 VM using a shell script that uses the same repositor and pom files works.
• We reproduced the error by write protecting one of the pom files, setting the versions, then removing the write protection and trying to set them again. It's possible this is happening earlier in the build somehow, but not sure how to troubleshoot if that's happening.

Any insights on how to resolve this issue would be greatly appreciated!

I figured out what was going wrong.

The parent module is actually a subdirectory in a git repository. We needed a pom.xml at the root of that repository just for keeping the dependency graph up to date so Dependabot could work. All it was is a minimal aggregator pom file that just pointed to the submodules, including the parent module mentioned in this post. The root-level aggregator pom was not intended to be part of a build though.

A step earlier in the workflow was setting the versions in another "parent project". We eventually noticed that when that project's versions were being set, it was first searching for a "local aggregator root", finding the pom we weren't intending to use, and finding the other parent projects through that, setting versions in those too. By the time it tried to set versions in the other parent projects, the versions were no longer as expected.

mvn versions:set, however, has this processFromLocalAggregationRoot option, that defaults to true. So I went in the workflow and added

-DprocessFromLocalAggregationRoot=false

to all the usages of mvn versions:set

That fixed it and allowed us to keep the pom file for Dependabot.