Remove init-script from readme

[mlykotom]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello @mlykotom, 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 refines the project's documentation by simplifying the gradlew commands listed in the README.md for code formatting and checking. The update removes an unnecessary flag, making the instructions more concise and user-friendly.

Highlights

• Documentation Update: I've updated the README.md file to simplify the instructions for running gradlew spotlessCheck and gradlew spotlessApply commands. The --init-script buildscripts/init.gradle.kts flag has been removed from these commands.
• Build Process Simplification: The change aims to streamline the process for checking and formatting individual samples, making the documented commands more direct and potentially reflecting an updated or simplified build setup.

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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 is currently in preview and 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 to provide feedback.

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 updates the README.md to simplify the commands for checking and formatting individual code samples by removing the --init-script flag from the gradlew spotlessCheck and gradlew spotlessApply commands. My review focuses on ensuring the correctness and consistency of these updated commands. A high-severity comment has been added to lines 79-80 of README.md, requesting confirmation that Spotless still functions as intended (correct configuration, execution, and rule application) within individual sample directories despite the removal of the init script. This verification is important because the init script might have played a crucial role in the Spotless setup that now needs to be handled by other means.

[gemini-code-assist]

These commands for checking and formatting individual samples have been simplified by removing the --init-script buildscripts/init.gradle.kts flag.

While this simplification is welcome, it's crucial to ensure that Spotless continues to function correctly and consistently. Specifically, please verify:

1. Configuration & Execution: Spotless must still be correctly configured and executable within individual sample directories without this init script. If the init script was responsible for applying necessary plugins or configurations that are not otherwise present in each sample's build.gradle file, these commands might now fail or behave unexpectedly.
2. Rule Consistency: The formatting rules applied or checked by spotlessCheck and spotlessApply should remain consistent with the project's overall standards. If the init.gradle.kts script enforced a common set of Spotless rules, its removal could lead to divergent formatting behaviors if samples don't individually define or inherit the same rules.

Could you confirm that these simplified commands have been thoroughly tested across various samples and that they achieve the intended formatting and checking outcomes, consistent with how they worked with the init script or as per current project standards?