search

ben-manes / gradle-versions-plugin

Gradle plugin to discover dependency updates
Apache License 2.0
3.82k stars 199 forks source link

Different result for CI/CD pipeline and local #820

Closed RowanG1 closed 7 months ago

RowanG1 commented 7 months ago

When running the version plugin locally on Mac and Ubuntu, I get the expected list of outdated libraries. But on pipeline, I get only 3 results. I am baffled as to what might be the cause of the discrepancy. I am using Gitlab for the pipeline. I even tried using a different docker image for Android.

ben-manes commented 7 months ago

Perhaps it is a caching issue? Can you try with —refresh-dependencies?

RowanG1 commented 7 months ago

Unfortunately, that did not work: Using fastlane command -> gradle(task: "dependencyUpdates", flags: "--refresh-dependencies")

ben-manes commented 7 months ago

hmm.. well that's not very much for me to advise on. You can use --info to inspect the gradle logs and why it resolved.

This plugin resolves a copy of your configuration and dependency with the dynamic version, +, and let Gradle do the work like it otherwise would. Does your CI has different restrictions, like using a repository cache, that do not apply when running locally? Sometimes dynamic queries resolve to stale maven-metadata.xml on a cached in a proxy whereas point lookups for absent versions are resolved anew.

RowanG1 commented 7 months ago

I am not aware of gitlab having restrictions. I even tried running the gitlab .yml on my local machine, but the result remains the same, even after removing the cache field on the gitlab script (previously it cached .gradle folder). Anyhow, I really appreciate your help.

ben-manes commented 7 months ago

yeah, I didn't know if you had a Nexus, Artifactory, etc. set up for your CI. Sometimes you'll see builds use that for improved reproducibility, e.g. when an external repository goes dark. I'd use the --info flag to inspect the logs and see how Gradle resolved a dependency, e.g. did it make the network requests, did it hit some resolution strategy or constraint, etc?

RowanG1 commented 7 months ago

The --info helped to find the issue, which showed that gradle properties were missing. I didn't realise that to run the dependency tool, all gradle properties need to be supplied, for all flavors.

ben-manes commented 7 months ago

oh good, Android has its quirks so I guess so? 🤷

RowanG1 commented 7 months ago

Sorry, I was mistaken about the comment: "all gradle properties need to be supplied, for all flavors". Actually, we use one private library, that is authenticated. Gradle needed the key/secret values for the library (which happens to be the same for all flavors).

ben-manes commented 7 months ago

oh thanks for the clarification. glad it is working now! hope you find it useful.