Adds Gemini CLI to Github Actions #2718
Conversation
I got carried away with Gemini and basically rewrote CI and the release process for the new LLM reality. - Bump all SDK versions to the current beta (3.9.0-0) - Run `flutter channel beta` - Wrote `ci_script.dart` to replace the bash scripts - Converted repository to pub workspace - Added llm.md and release.md - Added redirect for deprecated Samples Index ## Pre-launch Checklist - [x] I read the [Flutter Style Guide] _recently_, and have followed its advice. - [x] I signed the [CLA]. - [x] I read the [Contributors Guide]. - [x] I have added sample code updates to the [changelog]. - [x] I updated/added relevant documentation (doc comments with `///`).
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
📋 Review Summary
This PR introduces a comprehensive set of GitHub Actions workflows powered by the Gemini CLI to automate various repository management tasks, including PR reviews, issue triage, and general assistance. The workflows are well-structured and the prompts are detailed, which is great.
🔍 General Feedback
- The workflows are very powerful and will be a great addition to the repository.
- The prompts for the Gemini CLI are well-written and provide clear instructions.
- I've made a few suggestions to improve the readability and maintainability of the workflow files, mainly by simplifying conditions and commands.
- I've also pointed out a few potential issues in the prompt files that could be improved.
- There is one unrelated change in a
pubspec.yamlfile that seems to be a mistake.
Overall, this is a great PR that will significantly improve the automation of this repository.
add_to_app/android_view/flutter_module_using_plugin_android_view/pubspec.yaml
Outdated
Show resolved
Hide resolved
ericwindmill
changed the title
ericwindmill
changed the title
| 3. The checklist should only be maintained as a comment on the issue or PR. Do not track or update the checklist in code files. | ||
| - If the fix requires code changes, determine which files and lines are affected. If clarification is needed, note any questions for the user. | ||
| - Make the necessary code or documentation changes using the available tools (e.g., `write_file`). Ensure all changes follow project conventions and best practices. Reference all shell variables as `"${VAR}"` (with quotes and braces) to prevent errors. | ||
| - Run any relevant tests or checks to verify the fix works as intended. If possible, provide evidence (test output, screenshots, etc.) that the issue is resolved. |
There was a problem hiding this comment.
Would we want to/should we add an explicit step for dart analyze and dart fix somewhere here?
| } | ||
| } | ||
| prompt: |- | ||
| ## Role |
There was a problem hiding this comment.
For my own curiosity, would we at some point break this up until multiple agents - ex one that reviews code for readability, another for security, etc.? From the agent perspective I think that means that each agent has less context to manage and juggle. From our DRE perspective, I think it would make reading the prompts and I'd imagine (eventually) "debugging" it or updating for new models, easier?
Drive-by comment: I suggest adding agent style guidance to avoid this kind of language |
I very much appreciate the drive-by comment, thanks for the guidance! |
Pre-launch Checklist
///).