Skip to content

[ci] Add Gemini Code Assist review config #9632

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 16, 2025
+63 −15
Merged

[ci] Add Gemini Code Assist review config #9632

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
acbb670
[ci] Add Gemini Code Assist review config
stuartmorgan-g Jul 16, 2025
486c00b
Update repo tool filters
stuartmorgan-g Jul 16, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions .gemini/config.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
# Minimize verbosity.
have_fun: false
code_review:
# For now, use the default of MEDIUM for testing. Based on desired verbosity,
# we can change this to LOW or HIGH in the future.
comment_severity_threshold: MEDIUM
pull_request_opened:
# Explicitly set help to false in case the default changes in the future, as
# having a help message on every PR would be spammy.
help: false
# These tend to be verbose, and since we expect PR authors to clearly
# describe their PRs this would be at best duplicative.
summary: false
23 changes: 23 additions & 0 deletions .gemini/styleguide.md
View file
Open in desktop
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no idea how to know how well this will work. I tried to start with something reasonably concise, but that linked the most important documents, and I figure we can iterate from there if we are seeing patterns in the reviews that could potentially be addressed with additional guidance here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to iterate. Can we have it call out:

- Code should be formatted with `dart format`
- Code should pass `dart analyze`

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Code should be formatted with dart format

The file links to https://github.com/flutter/packages/blob/main/CONTRIBUTING.md#style which already says that, along with listing all of the other formatters we require. I'm really hoping that reference is enough, because I don't want to maintain two copies of that list forever.

  • Code should pass dart analyze

We already have CI that validates that. I don't really want to try to teach it all the CI requirements since:

  • That would be really unpleasant to maintain, since it would be a second copy our whole CI config.
  • It would presumably either a) not work because it wasn't actually running those commands, or b) be super wasteful because it would be running all the commands that CI is running just to give a second copy of the same feedback.
  • My primary goal here is to provide value to Flutter team members doing reviews, and they already know how to go look at the CI failures. (If we want to make that experience better via AI, I would recommend we build cross-repo tooling to teach some agent—maybe this one, maybe not—to understand and summarize all the failures in a set of LUCI tests on a PR, rather than try to teach the review agent what the commands our CI runs are).

Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Flutter Packages Style Guide

## Introduction

This style guide outlines the coding conventions for contributions to the
flutter/packages repository.

## Style Guides

Code should follow the relevant style guides, and use the correct
auto-formatter, for each language, as described in
[the repository contributing guide's Style section](https://github.com/flutter/packages/blob/main/CONTRIBUTING.md#style).

## Best Practices

- Code should follow the guidance and principles described in
[the flutter/packages contribution guide](https://github.com/flutter/flutter/blob/master/docs/ecosystem/contributing/README.md).
- Code should be tested. Changes to plugin packages, which include code written
in C, C++, Java, Kotlin, Objective-C, or Swift, should have appropriate tests
as described in [the plugin test guidance](https://github.com/flutter/flutter/blob/master/docs/ecosystem/testing/Plugin-Tests.md).
- PR descriptions should include the Pre-Review Checklist from
[the PR template](https://github.com/flutter/packages/blob/main/.github/PULL_REQUEST_TEMPLATE.md),
with all of the steps completed.
8 changes: 8 additions & 0 deletions .github/PULL_REQUEST_TEMPLATE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,14 @@

If you need help, consider asking for advice on the #hackers-new channel on [Discord].

**Note**: The Flutter team is currently trialing the use of
[Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code).
Comments from the `gemini-code-assist` bot should not be taken as authoritative
feedback from the Flutter team. If you find its comments useful you can
update your code accordingly, but if you are unsure or disagree with the
feedback, please feel free to wait for a Flutter team member's review for
guidance on which automated comments should be addressed.

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.

<!-- Links -->
Expand Down
33 changes: 18 additions & 15 deletions script/tool/lib/src/common/file_filters.dart
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,21 +8,24 @@
/// commands that are only affected by package code.
bool isRepoLevelNonCodeImpactingFile(String path) {
return <String>[
'AUTHORS',
'CODEOWNERS',
'CONTRIBUTING.md',
'LICENSE',
'README.md',
// This deliberate lists specific files rather than excluding the whole
// .github directory since it's better to have false negatives than to
// accidentally skip tests if something is later added to the directory
// that could affect packages.
'.github/PULL_REQUEST_TEMPLATE.md',
'.github/dependabot.yml',
'.github/labeler.yml',
'.github/post_merge_labeler.yml',
'.github/workflows/pull_request_label.yml',
].contains(path);
'AUTHORS',
'CODEOWNERS',
'CONTRIBUTING.md',
'LICENSE',
'README.md',
// This deliberate lists specific files rather than excluding the whole
// .github directory since it's better to have false negatives than to
// accidentally skip tests if something is later added to the directory
// that could affect packages.
'.github/PULL_REQUEST_TEMPLATE.md',
'.github/dependabot.yml',
'.github/labeler.yml',
'.github/post_merge_labeler.yml',
'.github/workflows/pull_request_label.yml',
].contains(path) ||
// This directory only affects automated code reviews, so cannot affect
// any package tests.
path.startsWith('.gemini/');
}

/// Returns true for native (non-Dart) code files, for use in command-ignored-
Expand Down
1 change: 1 addition & 0 deletions script/tool/test/xcode_analyze_command_test.dart
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -599,6 +599,7 @@ packages/package_a/$file
gitProcessRunner.mockProcessesForExecutable['git-diff'] =
<FakeProcessInfo>[
FakeProcessInfo(MockProcess(stdout: '''
.gemini/config.yaml
README.md
CODEOWNERS
packages/package_a/CHANGELOG.md
Expand Down