Bump Gradle to 8.5, fix cache.

[wwadge]

Updated https://github.com/GoogleContainerTools/jib/pull/4069 to not touch junit.

[wwadge]

Note: shift from port 5000 -> 5001 is because macOS is running AirPlay Receiver on the same port (settings -> Airdrop & Handoff -> AirPlay Receiver)

[loosebazooka]

Thanks for splitting it up!

[wwadge]

I understand that maybe you switching 5000 -> 5001 was needed for some local mac development, but it really does pollute this PR with a HUGE number of changed. Once again making it hard to review. I think isolating the logical changes in here from that massive change would make it easier to read and review (and not accidentally miss something).

Agree: removed the 5000 -> 5001 changes.

[wwadge]

Note: there's one more deprecated thing in place:

The StartParameter.settingsFile property has been deprecated. This is scheduled to be removed in Gradle 9.0. Setting custom build file to select the default project has been deprecated. Please use 'projectDir' to specify the directory of the default project instead.

This is coming from the researchgate plugin:

        at org.gradle.StartParameter.logBuildOrSettingsFileDeprecation(StartParameter.java:507)
        at org.gradle.StartParameter.getSettingsFile(StartParameter.java:497)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:323)
        at net.researchgate.release.ReleasePlugin$_apply_closure5.doCall$original(ReleasePlugin.groovy:107)
        at net.researchgate.release.ReleasePlugin$_apply_closure5.doCall(ReleasePlugin.groovy)

There's no update to the version we're using (v3.0.2) at time of writing

[loosebazooka]

Yeah it's okay about the research gate plugin. We'll deal with that later

[wwadge]

Can't see kokoro output, but if it's like last time might be worth waiting for gradle 8.5: https://github.com/gradle/gradle/issues/25752

[loosebazooka]

Yeah it's the same issue with the windows cache. One of the fixes was to move task.create -> task.register? Do we still have some task.create lying around?

nevermind, I found no references to create. I'll look for other types of eager evaluation.

[wwadge]

Huh - just literally now Gradle bumped to 8.5, let me try to update it

[loosebazooka]

Here's a few I found

diff --git a/build.gradle b/build.gradle
index a8ec1fe5..f5e1eaee 100644
--- a/build.gradle
+++ b/build.gradle
@@ -128,7 +128,7 @@ subprojects {
   }

   // Adds NullAway errorprone checks.
-  tasks.withType(JavaCompile) {
+  tasks.withType(JavaCompile).configureEach {
     if (!name.toLowerCase().contains('test')) {
       options.errorprone {
         check('NullAway', CheckSeverity.ERROR)
@@ -250,7 +250,7 @@ subprojects {

   /* JAVADOC ENFORCEMENT */
   // Fail build on javadoc warnings
-  tasks.withType(Javadoc) {
+  tasks.withType(Javadoc).configureEach {
     options.addBooleanOption('Xwerror', true)
   }
   assemble.dependsOn javadoc

[loosebazooka]

I chatted with gradle team and this fix for windows is not available till gradle 8.6. I think we don't need to be doing clean, but we might also just need to disable the cache on windows.

[wwadge]

I'm not well versed with kokoro at all, but I guess what you said translates to changing kokoro/presubmit.bat to read:

call gradlew.bat -Dorg.gradle.caching=false clean build --info --stacktrace

or dropping clean from there

?

[loosebazooka]

@wwadge been a while since I've used any of this tooling, @mpeddada1 can you see what it would require to get the windows build to work here (by removing clean or by disabling caching)?

[loosebazooka]

I think just remove "clean" from the windows build. Clean is unusual for gradle anyway.

[wwadge]

Removed clean from kokoro (windows) build

[mpeddada1]

Apologies for the delay, folks! Thanks for the suggestion @loosebazooka and making the edit @wwadge. Running the kokoro build.

[mpeddada1]

Looks like we're getting a slightly different error message now:

com.google.cloud.tools.jib.gradle.GradleProjectPropertiesTest > testGetMajorJavaVersion_jvm11 SKIPPED

com.google.cloud.tools.jib.gradle.JibExtensionTest > testProperties FAILED
    expected: \foo
    but was : C:\tmpfs\src\github\jib\jib-gradle-plugin\build\tmp\test\work\gradle1551860326683086368projectDir\foo
        at com.google.cloud.tools.jib.gradle.JibExtensionTest.testProperties(JibExtensionTest.java:525)

Hm it looks like the returned file path is resolving to the absolute path instead of the expected \foo.

[wwadge]

Looks like we're getting a slightly different error message now:

com.google.cloud.tools.jib.gradle.GradleProjectPropertiesTest > testGetMajorJavaVersion_jvm11 SKIPPED

com.google.cloud.tools.jib.gradle.JibExtensionTest > testProperties FAILED
    expected: \foo
    but was : C:\tmpfs\src\github\jib\jib-gradle-plugin\build\tmp\test\work\gradle1551860326683086368projectDir\foo
        at com.google.cloud.tools.jib.gradle.JibExtensionTest.testProperties(JibExtensionTest.java:525)

Hm it looks like the returned file path is resolving to the absolute path instead of the expected \foo.

I changed the way from(..) was implemented, let's try again with the new implementation that I just pushed

[loosebazooka]

com.google.cloud.tools.jib.gradle.JibExtensionTest > testProperties FAILED
    expected: \foo
    but was : C:\tmpfs\src\github\jib\jib-gradle-plugin\build\tmp\test\work\gradle5672696465279302889projectDir\foo
        at com.google.cloud.tools.jib.gradle.JibExtensionTest.testProperties(JibExtensionTest.java:525)

[wwadge]

Hopefully this latest commit is close enough to how it was and works - I cannot revert completely because we used "project.file" previously. I will try to obtain a windows box to test if this one fails too for I'm still working a bit blind.

[sonarqubecloud[bot]]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
86.3% Coverage on New Code
1.7% Duplication on New Code

See analysis details on SonarCloud

[wwadge]

One more kokoru run please - I reverted that .toAbsolutePath() bit we had added to our tests. Now that I reverted how I'm handling paths, I needed to revert that .toAbsolutePath() bit too.

Seems to work on a local windows box.

[loosebazooka]

@mpeddada1 I think this is ready for another review

[blakeli0]

@wwadge Thanks for submitting this PR and all the effort! @loosebazooka Thanks for putting the effort reviewing the PR! Unfortunately, as I mentioned in the comment, after careful consideration, we don't want to introduce a breaking change for customers still use Gradle < 8 at this moment. So we can not accept this PR as it is right now, we may re-visit it once we feel comfortable to move the minimum supported version for jib to 8.

We are really sorry for the back and forth in the past few months, please let us know if you have other suggestions!