Closed BlueVirusX closed 1 year ago
Hi, this needs reproduction in a public github.com repository in order to be debugged.
This is similar/related to #4910.
@rarkins Hi, I tried to create a reproduction sample, but the renovate bot has some problems with my repository.
WARN: Gradle extraction failed
{
"errMessage": "Command failed: docker run --rm -v \"/mnt/renovate/gh/BlueVirusX/renovate_issue_5619\":\"/mnt/renovate/gh/BlueVirusX/renovate_issue_5619\" -v \"/tmp/renovate-cache\":\"/tmp/renovate-cache\" -w \"/mnt/renovate/gh/BlueVirusX/renovate_issue_5619\" renovate/gradle bash -l -c \"./gradlew --init-script renovate-plugin.gradle renovate\"\n"
}
Any ideas why gradle extraction is failing?
When I debug it locally I get stdout: "JAVA_HOME not set and cannot find javac to deduce location, please set JAVA_HOME."
@viceice do you think we have a problem with our renovate/gradle
image?
@rarkins Can I do anything to resolve this JAVA_HOME
issue?
@rarkins The issue with the gradle extraction seems to be gone since April 20th 👍
Now the issue with dependencies with multiple classifiers can be seen in that PR. Only the dependency without any classifier is updated and there are not other PRs.
According to the logs (e.g. the packageFiles with updates
debug log), is this detected as a single dependency in that file or 3 dependencies?
As far as I understand the log, renovate detects the dependence three times, but without any classifier.
@BlueVirusX can you retry with the latest release of Renovate? This fix I made yesterday may be relevant: https://github.com/renovatebot/renovate/commit/f61c416f8a0d5dff170b078caa5fda1012534999
The PR in the sample repo is still missing the updates for the dependencies with classifiers:
Version of 'com.google.inject:guice:3.0' is updated, but version of 'com.google.inject:guice:3.0:no_aop' and 'com.google.inject:guice:3.0:javadoc' are not updated.
Before commit:
dependencies {
implementation 'com.google.inject:guice:3.0'
implementation 'com.google.inject:guice:3.0:no_aop'
implementation 'com.google.inject:guice:3.0:javadoc'
}
After commit:
dependencies {
implementation 'com.google.inject:guice:4.2.3'
implementation 'com.google.inject:guice:3.0:no_aop'
implementation 'com.google.inject:guice:3.0:javadoc'
}
@rarkins Is there anything I could do to bring this issue further? For me it seems like renovate can't differentiate between the base dependency and the dependencies with classifiers.
I've attached some logs before and after updating the base dependency. There you can see that "com.google.inject:guice" is found 3 times, but always without a classifier. After updating the base dependency the versions of all packages is updated. After removing the base dependency renovate still finds 3 updates, but instead of updating the version of the base dependency (which has been removed from 'build.gradle') renovate updates the first dependency with a classifier.
I think part of the challenge is that we haven't come across classifiers before. Two possible approaches:
The second approach is probably OK as long as we don't need the classifier as part of the lookup
This reproduction has been forked to https://github.com/renovate-reproductions/5619
Needs validation against the current Gradle manager
I've experienced what I believe is this issue as well, in https://github.com/KyoriPowered/indra/pull/70.
My buildscript has:
compileOnlyApi "org.immutables:value:2.8.8:annotations"
annotationProcessor "org.immutables:value:2.8.8"
compileOnlyApi "org.immutables:builder:2.8.8"
When renovate opens a PR to update this issue, it only updates the variant of org.immutables:value
without a classifier -- see https://github.com/KyoriPowered/indra/commit/5c307b7373a6e653a625a4c6cbfd0f8d18adcc1a
Hi there,
Help us by making a minimal reproduction repository.
Before we can start work on your issue we first need to know exactly what's causing the current behavior. A minimal reproduction helps us with this.
To get started, please read our guide on creating a minimal reproduction to understand what is needed.
We may close the issue if you (or someone else) have not provided a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment.
Good luck,
The Renovate team
I've created a reproducer at https://github.com/zml2008/renovate-issue-5619-reproducer
See https://github.com/zml2008/renovate-issue-5619-reproducer/pull/1 for the incorrect output, with a review comment indicating the expected output.
@zml2008 thanks for your reproduction, including explanation here: https://github.com/zml2008/renovate-issue-5619-reproducer/pull/1#discussion_r800022441
It's possible to use a workaround until it's being fixed:
def vertxVersion = '4.2.6'
dependencies { implementation "io.vertx:vertx-core:${vertxVersion}" implementation "io.vertx:vertx-web:${vertxVersion}" implementation "io.vertx:vertx-web-client:${vertxVersion}" implementation "io.vertx:vertx-web-openapi:${vertxVersion}" implementation "io.vertx:vertx-web-api-service:${vertxVersion}" implementation "io.vertx:vertx-service-proxy:${vertxVersion}" annotationProcessor "io.vertx:vertx-codegen:${vertxVersion}:processor" annotationProcessor "io.vertx:vertx-web-api-service:${vertxVersion}"
your reproduction repository doesn't have classifiers
the results changed in the latest version it now doesn't update it at all:
is this the correct behaviour? or does it need to update to 2.9.0:annotations?
What Renovate type are you using?
I am using self-hosted Renovate in combination with a self-hosted Gitlab instance.
Describe the bug
Currently I am facing a bug when using classifiers. I have some dependencies which use the same group and name but different classifiers. Like this:
Problem 1: When the a new version of the dependency is available Renovate creates only a MR for the fist classifier, not for the second classifier.
Problem 2: When the a new version of the dependency is available the version strings of both classifiers should be updated in one MR.
Did you see anything helpful in debug logs?
Currently I haven't got any useful logs.
To Reproduce
Currently I have no public Repo available, but the bug should be reproducable with something similar to the bug description.
Additional context
The dependencies are declared in a gradle subproject not on the root project (don't know if this matters).