Fix `bazel test //...`
Summary of Changes
Hello @fmeum, I'm Gemini Code Assist[^1]! 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 streamlines the Bazel CI presubmit configuration by consolidating the test_targets definitions. It replaces verbose, explicit lists of test paths with a more concise //... pattern, while also introducing an explicit exclusion for //third_party/.... This change aims to ensure that bazel test //... correctly identifies and executes relevant tests across different operating systems within the CI pipeline, improving maintainability and clarity of the test configuration.
Highlights
- CI Test Target Simplification: The
test_targetsconfiguration in.bazelci/presubmit.ymlhas been significantly simplified across multiple CI tasks (linux, macos, windows, ubuntu2004_java11). - Broadened Test Scope: Instead of an explicit, lengthy list of individual test paths, the configuration now uses
//...to include all targets. - Third-Party Exclusion: A specific exclusion
-//third_party/...has been added to prevent testing of third-party dependencies, which is a common practice to focus on first-party code.
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 |
|---|---|---|
| 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 pull request 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 may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with :thumbsup: and :thumbsdown: 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.
[^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.
@meteorcloudy This is green locally, but I don't know how to ensure that target determination doesn't explicitly request Windows-only targets. @gregestren for ctexplain
Currently we are resolving those test targets for sharding at https://github.com/bazelbuild/continuous-integration/blob/a1dfff1694bc39b07454d3d50cf2c2973c1308d5/buildkite/bazelci.py#L2270-L2279
@fweikert tried to switch to using cquery from query (EXP_USE_CQUERY), maybe that would help, but we probably encountered other problems.
Alternatively, we could make this a warning optionally?
Maybe we can also just bazel query to exclude bazel query 'attr(target_compatible_with, "@platforms//os:windows", tests(//...))'
I can try with Gemini
https://github.com/bazelbuild/continuous-integration/pull/2419
@fmeum Looks like there are still other test failures like //tools/ctexplain:lib_test
Also, please sync to HEAD, just in case there are new breaking tests.
I will rebase and fix the remaining tests when your fix has been deployed. I don't want to miss any tests masked by the build failure.