Complex yet valid maven project fails with `dependency_file_not_evaluatable {message: "ERROR: Invalid expression: /project/groupId}.channel"}`
Is there an existing issue for this?
- [x] I have searched the existing issues
Package ecosystem
maven
Package manager version
No response
Language version
java
Manifest location and content before the Dependabot update
https://github.com/wildfly/wildfly/blob/main/pom.xml
dependabot.yml content
Nothing special here.
# https://docs.github.com/github/administering-a-repository/configuration-options-for-dependency-updates
version: 2
registries:
maven-central:
type: maven-repository
url: https://repo.maven.apache.org/maven2/
jboss-public-repository-group:
type: maven-repository
url: https://repository.jboss.org/nexus/content/groups/public/
updates:
- package-ecosystem: "maven"
directory: "/"
schedule:
interval: "daily"
ignore:
# Only allow for patch release upgrades
- dependency-name: '*'
update-types: ['version-update:semver-major', 'version-update:semver-minor']
# WildFly Clustering updates are usually non-trivial
- dependency-name: 'org.wildfly.clustering:*'
# Dependencies exclusive to Hibernate Search:
# we'll only upgrade those when we upgrade to a newer version of Hibernate Search.
- dependency-name: 'org.elasticsearch.client:*'
- dependency-name: 'org.apache.lucene:*'
- dependency-name: 'com.carrotsearch:hppc'
- dependency-name: 'org.apache.avro:avro'
rebase-strategy: "disabled"
open-pull-requests-limit: 10
registries:
- maven-central
- jboss-public-repository-group
- package-ecosystem: "github-actions"
# Workflow files stored in the
# default location of `.github/workflows`
directory: "/"
schedule:
interval: "daily"
Updated dependency
No response
What you expected to see, versus what you actually saw
What we are seeing: https://gist.github.com/bstansberry/5bbd2b64ac324421628c08958c4210b8
dependency_file_not_evaluatable {message: "ERROR: Invalid expression: /project/groupId}.channel"}
And why it's clear that it's a dependabot issue: there is no such property "channel" anywhere in the pom, only "channels". Something is being parsed incorrectly by dependabot.
Native package manager behavior
No response
Images of the diff or a link to the PR, issue, or logs
https://gist.github.com/bstansberry/5bbd2b64ac324421628c08958c4210b8
Smallest manifest that reproduces the issue
Impossible to isolate into a small reproducer.
Is your repository private? Without a reproducer, it'll be quite hard to help here from an OSS perspective
Is your repository private? Without a reproducer, it'll be quite hard to help here from an OSS perspective
@yeikel Not at all – it's a well-known OSS – https://github.com/wildfly/wildfly
Perhaps a GH employee could access? https://github.com/wildfly/wildfly/network/updates/15651923/jobs - if not I can upload more logs than in the report.
Dependabot encountered an unknown error
Dependabot failed to update your dependencies because an unexpected error occurred. See the logs for more details.
[Troubleshoot Dependabot errors](https://docs.github.com/github/managing-security-vulnerabilities/troubleshooting-dependabot-errors)
Thanks, I was on mobile and missed that you put the repo link
The good news is that it is easily reproducible: https://github.com/yeikel/wildfly/actions/runs/19968060860/job/5726
I'll try to see if can create a minimum reproducer from here
@yeikel Excellent, let me know if I can be of help in any way.
This is a minimum reproducer that shows the problem
<?xml version="1.0" encoding="UTF-8"?>
<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>org.reproducer</groupId>
<artifactId>test</artifactId>
<version>1.0.0-SNAPSHOT</version>
<properties>
<channels.maven.groupId>${project.groupId}.channels</channels.maven.groupId>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>${channels.maven.groupId}</groupId>
<artifactId>wildfly-preview</artifactId>
<version>19.0.0.Final</version>
</dependency>
</dependencies>
</dependencyManagement>
</project>
This produces
updater | +-------------------------------------------------------------------------------------------------------+
updater | | Errors |
updater | +---------------------------------+---------------------------------------------------------------------+
updater | | Type | Details |
updater | +---------------------------------+---------------------------------------------------------------------+
updater | | dependency_file_not_evaluatable | { |
updater | | | "message": "ERROR: Invalid expression: /project/groupId}.channel" |
updater | | | } |
updater | +---------------------------------+---------------------------------------------------------------------+
The issue boils down to the fact that Dependabot seems to be unable to resolve dynamic properties like
<channels.maven.groupId>${project.groupId}.channels</channels.maven.groupId>
Because using this instead solves the issue
<properties>
<channels.maven.groupId>org.reproducer.channels</channels.maven.groupId>
</properties>
I don't have a fix for this yet, but this is what seems to be the problem
@yeikel Excellent stuff, thanks for the thorough investigation. What is a bit puzzling is that this line is there in our main branch since Sep 27, 2024 and dependabot only started failing with it recently(-ish).
I will see if I can workaround the issue in WildFly as you suggested, by hardcoding the property.
@yeikel Excellent stuff, thanks for the thorough investigation. What is a bit puzzling is that this line is there in our main branch since Sep 27, 2024 and dependabot only started failing with it recently(-ish).
Yeah, to be honest it was hard to reproduce. I ran the job multiple times and the failure was flaky and sometimes it would pass. Only via the CLI I was able to reproduce it consistently
I will see if I can workaround the issue in WildFly as you suggested, by hardcoding the property.
Keep me posted!
When I look at the job history of your repo, I also see this flaky nature.
Here is a failure from 3 months ago with the same issue: https://github.com/wildfly/wildfly/actions/runs/17622689030/job/50071882269
But right after that job, it worked just fine
I find this strange and it suggests some dynamic parsing logic that is not always triggered. I'll investigate and let you know if I can find out why
I raised #13746 which attempts to fix this problem