This message was deleted.
# community-support
s
This message was deleted.
c
hard to diagnose with out a reproducible minimal project. The failing project possibly isn’t using the same settings.gradle that defines the versions.
βœ… 1
It may be worth reviewing the working directories used to execute each build vs locations of
settings.gradle
file(s). There is a documented search path for settings.gradle.
βœ… 1
Particularly this:
Gradle supports arbitrary physical layouts for a multi-project build, but for such arbitrary layouts you need to execute the build from the directory where the settings file is located.
πŸ‘€ 1
e
As is often the case, a reproducible minimal project can be very difficult to construct, and because of intellectual property issues, I cannot just share everything... Yes, I will have to dig in and understand our GitLab pipeline more than I wanted to... My personal philosophy is to put as much build logic in the build tools like Maven, SBT, Gradle, etc. However, this seems antithetical to most build pipeline engineers who believe their scripts are always better than the build tools... as they would rather not edit files like
setting.gradle
and
build.gradle
...
c
perhaps start with an empty representative project layout (no source, just build files) and work from there to narrow things down.
e
I think I need to understand the YAML files in the pipeline that are launching Gradle, because they are using the same gradle files, but there may be some other contextual differences...
c
this should be reproducible w/o the build pipeline by executing the same gradle commands (e.g.
./gradlew build
) in the same project directories.
βœ… 1
e
okay... will start there...
v
Maybe one pipeline injects some init scripts that break things
c
could be. also worth checking if there are multiple settings.gradle files in play.
init scripts would be evident on the Gradle command line, or perhaps in scripting that places files in certain locations.
v
Also in the info (or latest in the debug) logs they should be mentioned
If possible you could also share a build scan
c
ah yea, good point.
e
I will try to see if I can reproduce locally first, as Chris suggests...
πŸ‘Œ 1
Okay, problem solved... the same
build.gradle
file, different
settings.gradle
files... Different pipeline builders ran gradle in different project directories, with different
settings.gradle
files, but in our mono repo, with project dependency chaining the way we are doing it, it was chaining to the same
build.gradle
file, and I did not realize it... Running the build script locally resolved the problem, so @Chris Lee wins the free beer... πŸ₯³
πŸ‘Œ 1
c
Glad this worked out 🍻
πŸ™Œ 1
e
I have sure learned a lot about gradle here... I am promoting this Slack site at work...
πŸ‘Œ 1
v
Yeah, having a project part of multiple builds is seldomly a good idea. Usually a project should always only belong to one build and if you need it in another build you should use composite builds.
βœ… 1