After migrating to Gradle 9, I get a build error, ...
# community-support
s
After migrating to Gradle 9, I get a build error, but only when building my project inside a Docker contain as part of a GitHub Action, see this. The error message is `Configuring project 'utilstest-utils' without an existing directory is not allowed. The configured projectDirectory '/home/ort/src/ort/utils/test' does not exist, can't be written to or is not a directory.`Locally, on a native machine, the build works fine. Also, the CI build in Docker works fine with Gradle 8.14.3. Any idea what change in Gradle 9 is causing this?
v
Probably what the error message is telling you 🙂
It was always ok to have a project without project directory.
s
But why is it a problem now, if it wasn't before?
v
But this also meant that you can have a typo and the project directory might not be what you think
And this is even worse if you throw case-insensitive filesystems into play
That means you develop on typical windows and have a difference in casing, everything works fine
Then your colleague or CI wants to build on typical CI and the project suddenly does not have any content anymore
I remember an issue to deprecate having a project without project directory to more easily recognize and identify such situations, I guess in 9 this now is in as hard error?
I would hope it produced a deprecation warning before
Maybe you generate these directories as part of your build and locally you already have the files there so the error does not trigger?
s
Not that I'm aware of.
utils/test
is a directory committed in Git, with a regular project inside, and that's we bind-mount to the Docker container. Which is running Linux as a guest, not Windows.
v
Hm, then it is strange
But at least it behaves like I described, if the dir is not found you get a deprecation warning with 8 and a failure with 9, just double-checked. 😕
s
You mean this deprecation warning with Gradle 8.14.3, I guess? A bit inconvenient that no actual deprecation warning is shown. I'll try with
--warning-mode all
.
v
Probably, I tend to forget that the actual warnings are not displayed by default, because I have
org.gradle.warning.mode = all
in my
<GRADLE_USER_HOME>/gradle.properties
so I get them displayed always.
👍 1
But like usual, the smoothed Gradle upgrade path is • update to latest patch version within same major version • update all plugins to latest compatible version • fix all deprecation warnings • update to the latest patch version in the directly following major version • go to second step and iterate until reaching the target version
Build Scans also show the deprecations always, independent of that switch iirc
Deprecation warnings are not evil as long as you stay within the same major version, so displaying them on each invocation would be overkill. They only become a real problem once you want to upgrade to the next major version where in most cases the deprecations become errors.
s
> I have
org.gradle.warning.mode = all
in my
<GRADLE_USER_HOME>/gradle.properties
so I get them displayed always.
Deprecation warnings are not evil as long as you stay within the same major version, so displaying them on each invocation would be overkill.
How do these statements fit together?
p
„utils“ is not a Gradle project
you include „utils:test“ so Gradle adds two projects „utils“ AND „test“, but utils is not an actual project.
s
Ah, wow, so having empty directories for grouping along to the path to nested subprojects is not allowed anymore?
And I need to add dummy parent Gradle projects for that?
v
Of course
utils
is a Gradle project
And the directory is there
And it also is not what is complained about
It complains about
utils/test
not being present
p
Hm, but it is a dummy empty project without a build file 🤔
v
Having an empty directory as project directory and no build script is fine, that does not mean it is no Gradle project
It is not dummy
p
Oh okay
v
It is a project like any other
It just has no configuration (unless badly done through cross-project configuration)
s
Thanks everybody for your help!
👌 1