4052: remove deprecated getSettingsFile usage

[wallind]

See https://docs.gradle.org/current/userguide/upgrading_version_8.html#configuring_custom_build_layout

Thank you for your interest in contributing! For general guidelines, please refer to
the contributing guide.

Please follow the guidelines below before opening an issue or a PR:

• Ensure the issue was not already reported. -> it was, and I'm working off that When skaffold invokes jib via gradle, a deprecated feature is used that will not work on gradle 9.0 #4052
• Discuss the priority and potential solutions with the maintainers in the issue. The maintainers would review the issue and add a label "Accepting Contributions" once the issue is ready for accepting contributions.
• Open a PR only if the issue is labeled with "Accepting Contributions", ensure the PR description clearly describes the problem and solution. Note that an open PR without an issues labeled with "Accepting Contributions" will not be accepted. This label doesn't seem to exist?

• Verify that integration tests and unit tests are passing after the change.
• Address all checkstyle issues. Refer to the style guide.

Fixes #4052 🛠️

[gemini-code-assist]

Summary of Changes

Hello @wallind, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request updates the Jib Gradle plugin to remove usage of a deprecated Gradle API method for retrieving settings files. The change ensures continued compatibility with newer Gradle versions, specifically addressing recommendations for Gradle 8, by directly resolving and checking for the existence of both Groovy and Kotlin DSL settings files.

Highlights

• Gradle API Update: Replaced the deprecated getSettingsFile() method with a modern approach for locating Gradle settings files, aligning with Gradle 8 recommendations.
• Enhanced Settings File Detection: The plugin now explicitly checks for both settings.gradle (Groovy DSL) and settings.gradle.kts (Kotlin DSL) files, improving compatibility and robustness.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request aims to remove the usage of a deprecated Gradle API, getSettingsFile(). While the change successfully removes the deprecated call, it introduces a functional regression by no longer supporting custom settings file locations. My review provides a detailed suggestion on how to correctly address the deprecation using the BuildLayout service, which would also fix the regression. This involves a slightly larger refactoring of the FilesTaskV2 task.

[wallind]

Code Review

This pull request aims to remove the usage of a deprecated Gradle API, getSettingsFile(). While the change successfully removes the deprecated call, it introduces a functional regression by no longer supporting custom settings file locations. My review provides a detailed suggestion on how to correctly address the deprecation using the BuildLayout service, which would also fix the regression. This involves a slightly larger refactoring of the FilesTaskV2 task.

So Gemini is right, but that's just the nature of the change here that it's a breaking change I think.

curious what maintainers think.

[wallind]

@gemini-code-assist see here https://docs.gradle.org/9.0.0/userguide/upgrading_major_version_9.html#removal_of_custom_build_layout_options, supporting --settings-file is done for.

[gemini-code-assist]

Thank you for the clarification, @wallind. I understand that the removal of support for custom settings file locations via --settings-file is an intentional breaking change, rather than an unintended regression. My previous suggestion was based on the assumption of maintaining existing functionality, but if this change is indeed by design, then the current implementation correctly reflects that intent. The decision to introduce a breaking change, and its implications, will ultimately be up to the project maintainers.