Skip to content

Introduce flags to allow filtering of targets by rule name #7

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.

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

arvi18
Copy link

@arvi18 arvi18 commented Apr 16, 2025

Introduce two new flags to allow for filtering of targets based on rule name:

  • --build_rule_filters
  • --test_rule_filters

Summary by CodeRabbit

  • New Features

    • Added support for filtering build and test targets by rule names using new command-line options.
    • Users can now specify rule name filters (including exclusions) to restrict which targets are built or tested.
    • Test filtering now supports rule name-based criteria in addition to existing filters.
  • Bug Fixes

    • Improved equality checks for internal filter representations to ensure correct behavior with new rule filters.
  • Tests

    • Added and updated tests to validate rule name filtering functionality for both build and test targets.

This commit introduces two new flags: `--build_rule_filters` &
`--test_rule_filters`. They behave in a very similar manner to
existing filter flags, e.g. tag, timeout, size, lang, etc., and will
allow users to filter out or in targets for building/testing that
use a specific rule.
@visz11
Copy link
Collaborator

visz11 commented Apr 23, 2025

@coderabbitai full review

Copy link

coderabbitai bot commented Apr 23, 2025

✅ Actions performed

Full review triggered.

Copy link

coderabbitai bot commented Apr 23, 2025

Walkthrough

This change introduces rule name-based filtering for build and test targets across several components. New command-line options allow users to specify rule name filters for both build and test operations. Supporting methods and fields were added to core classes to parse, store, and apply these filters. The filtering logic is implemented analogously to existing tag-based filters, and the relevant predicates are applied during target pattern resolution and test filtering. Comprehensive tests were added or updated to validate the new rule filter functionality in both production and test code.

Changes

File(s) Change Summary
src/main/java/com/google/devtools/build/lib/packages/TargetUtils.java
src/main/java/com/google/devtools/build/lib/packages/TestTargetUtils.java
Added static methods for rule name-based filtering: ruleFilter in TargetUtils and testMatchesRuleFilters in TestTargetUtils.
src/main/java/com/google/devtools/build/lib/pkgcache/LoadingOptions.java Added two new command-line options: build_rule_filters and test_rule_filters, with corresponding public fields.
src/main/java/com/google/devtools/build/lib/pkgcache/TestFilter.java Extended TestFilter to support rule name-based filtering, updated constructor, factory method, and equality/hash logic.
src/main/java/com/google/devtools/build/lib/skyframe/SkyframeExecutor.java Modified call to TargetPatternPhaseValue.key to include build rule filters.
src/main/java/com/google/devtools/build/lib/skyframe/TargetPatternPhaseFunction.java Applied rule filter in addition to tag filter when merging resolved targets.
src/main/java/com/google/devtools/build/lib/skyframe/TargetPatternPhaseValue.java Added buildRuleFilter field to TargetPatternPhaseKey, updated constructors, factory methods, getter, and equality logic.
src/test/java/com/google/devtools/build/lib/packages/TargetUtilsTest.java Added tests for rule name-based filtering using TargetUtils.ruleFilter.
src/test/java/com/google/devtools/build/lib/packages/TestTargetUtilsTest.java Added tests for filtering by language and rule name using TestFilter.
src/test/java/com/google/devtools/build/lib/skyframe/TargetPatternPhaseKeyTest.java Updated helper methods and test calls to include the new build rule filter argument.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant LoadingOptions
    participant SkyframeExecutor
    participant TargetPatternPhaseValue
    participant TargetPatternPhaseFunction
    participant TargetUtils

    User->>LoadingOptions: Specify --build_rule_filters / --test_rule_filters
    LoadingOptions->>SkyframeExecutor: buildRuleFilterList / testRuleFilterList
    SkyframeExecutor->>TargetPatternPhaseValue: key(..., buildRuleFilterList)
    TargetPatternPhaseValue->>TargetPatternPhaseFunction: getBuildRuleFilter()
    TargetPatternPhaseFunction->>TargetUtils: ruleFilter(buildRuleFilterList)
    TargetUtils-->>TargetPatternPhaseFunction: Predicate<Target>
    TargetPatternPhaseFunction->>TargetPatternPhaseFunction: Filter ResolvedTargets with predicate
    TargetPatternPhaseFunction-->>User: Filtered targets
Loading

Poem

In the warren of rules, a new filter appears,
Sorting out targets as the build dust clears.
With names on a list—some in, some out—
The builder is nimble, no need to shout!
Now tests and their kin can hop through with pride,
For rule-based selection is here to provide.
🐇✨

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 ast-grep (0.31.1)
src/main/java/com/google/devtools/build/lib/skyframe/SkyframeExecutor.java
✨ Finishing Touches
  • 📝 Generate Docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 0

🔭 Outside diff range comments (1)
src/main/java/com/google/devtools/build/lib/skyframe/TargetPatternPhaseValue.java (1)

290-301: ⚠️ Potential issue

Missing buildRuleFilter in hashCode method

The buildRuleFilter field is included in the equals method but not in the hashCode method. This inconsistency can lead to bugs when the object is used in hash-based collections.

Add the buildRuleFilter field to the hashCode method:

  @Override
  public int hashCode() {
    return Objects.hash(
        targetPatterns,
        offset,
        compileOneDependency,
        buildTestsOnly,
        determineTests,
+       buildTargetFilter,
+       buildRuleFilter,
        buildManualTests,
        expandTestSuites,
        testFilter);
  }
🧹 Nitpick comments (1)
src/test/java/com/google/devtools/build/lib/packages/TargetUtilsTest.java (1)

130-132: Fix comment to reference rules instead of tags

The comment refers to "tag" but this test is about rule filtering, not tag filtering.

-    // Applying same tag as positive and negative filter produces an empty
+    // Applying same rule name as positive and negative filter produces an empty
     // result because the negative filter is applied first and positive filter will
     // not match anything.
📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c0c98a2 and e2f9700.

📒 Files selected for processing (10)
  • src/main/java/com/google/devtools/build/lib/packages/TargetUtils.java (1 hunks)
  • src/main/java/com/google/devtools/build/lib/packages/TestTargetUtils.java (1 hunks)
  • src/main/java/com/google/devtools/build/lib/pkgcache/LoadingOptions.java (1 hunks)
  • src/main/java/com/google/devtools/build/lib/pkgcache/TestFilter.java (6 hunks)
  • src/main/java/com/google/devtools/build/lib/skyframe/SkyframeExecutor.java (1 hunks)
  • src/main/java/com/google/devtools/build/lib/skyframe/TargetPatternPhaseFunction.java (1 hunks)
  • src/main/java/com/google/devtools/build/lib/skyframe/TargetPatternPhaseValue.java (8 hunks)
  • src/test/java/com/google/devtools/build/lib/packages/TargetUtilsTest.java (1 hunks)
  • src/test/java/com/google/devtools/build/lib/packages/TestTargetUtilsTest.java (1 hunks)
  • src/test/java/com/google/devtools/build/lib/skyframe/TargetPatternPhaseKeyTest.java (12 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (2)
src/main/java/com/google/devtools/build/lib/skyframe/TargetPatternPhaseFunction.java (1)
src/main/java/com/google/devtools/build/lib/packages/TargetUtils.java (1)
  • TargetUtils (44-455)
src/main/java/com/google/devtools/build/lib/packages/TargetUtils.java (1)
src/main/java/com/google/devtools/build/lib/packages/TestTargetUtils.java (1)
  • TestTargetUtils (27-151)
🔇 Additional comments (20)
src/main/java/com/google/devtools/build/lib/skyframe/TargetPatternPhaseFunction.java (1)

370-373: Clean implementation of rule filtering

The addition of rule filtering alongside the existing tag filtering is well-implemented and follows the established pattern. This change correctly applies the rule filter predicate from TargetUtils.ruleFilter() to the builder before constructing the final ResolvedTargets<Target> result.

src/main/java/com/google/devtools/build/lib/skyframe/SkyframeExecutor.java (1)

3004-3005: Build rule filters correctly integrated

The change correctly adds support for rule-based filtering in the target pattern loading process, passing the newly introduced buildRuleFilterList as an argument to the TargetPatternPhaseValue.key method. This follows the same pattern as the existing tag filters, maintaining consistency.

src/main/java/com/google/devtools/build/lib/packages/TestTargetUtils.java (1)

94-104: Implementation looks good!

The testMatchesRuleFilters method follows a clean and consistent pattern similar to the existing tag filtering methods. The logic is straightforward and correctly implements the rule filtering requirements.

src/test/java/com/google/devtools/build/lib/packages/TargetUtilsTest.java (1)

99-139: Well-structured test for rule filtering functionality

The test implementation thoroughly verifies the rule filtering functionality with various combinations of positive and negative rule name filters. It properly tests all the key scenarios including empty filters, single rule filters, negative filters, and combinations.

src/main/java/com/google/devtools/build/lib/packages/TargetUtils.java (1)

384-405: Implementation looks good!

The ruleFilter method is well-implemented, following the same pattern as the existing tagFilter method. It correctly reuses the sortTagsBySense utility method to separate positive and negative filters and returns a predicate that properly checks rule class names against the filter lists.

src/main/java/com/google/devtools/build/lib/pkgcache/LoadingOptions.java (2)

131-145: Command-line option well defined

The build_rule_filters option follows the established pattern of other filter options. The help text clearly explains its purpose and behavior.


146-159: Command-line option well defined

The test_rule_filters option is well-defined and consistent with other test filter options. The help text clearly explains its purpose and behavior.

src/test/java/com/google/devtools/build/lib/packages/TestTargetUtilsTest.java (2)

117-142: Comprehensive test coverage for language filtering

Good addition of test methods to verify the functionality of language filtering. The test properly creates mock objects and validates both positive and negative language filters.


144-169: Well-structured test for rule-based filtering

This new test method correctly validates the rule filtering feature, ensuring that both positive and negative rule filters work as expected. The test setup follows the same pattern as the language filter test, which ensures consistency.

src/main/java/com/google/devtools/build/lib/skyframe/TargetPatternPhaseValue.java (4)

158-159: Good addition of buildRuleFilter parameter

The parameter is correctly added to the key method signature and passed to the constructor.

Also applies to: 169-170


186-187: Proper update to keyWithoutFilters

The keyWithoutFilters method is correctly updated to include an empty list for the new buildRuleFilter parameter.


199-200: Proper implementation of buildRuleFilter

The field is correctly added, initialized in the constructor, and a getter method is provided.

Also applies to: 211-212, 221-222, 259-261


317-318: Field included in equals method

The buildRuleFilter field is correctly incorporated into the equals method.

src/main/java/com/google/devtools/build/lib/pkgcache/TestFilter.java (4)

49-51: Good addition of testRuleFilterList

The new field is properly added to the class, parameters, and constructor.

Also applies to: 57-58, 65-66, 71-72


85-87: Proper handling of rule filters

The implementation correctly checks if the rule filter list is not empty and applies the filter.


99-100: Fields properly included in hashCode, equals, and toString

The testRuleFilterList field is consistently incorporated into all object methods.

Also applies to: 113-115, 124-125


172-194: Well-implemented testRuleFilter method

The implementation follows the same pattern as the testLangFilter method, properly separating required and excluded rules. The filtering logic is correct and consistent with the existing code style.

src/test/java/com/google/devtools/build/lib/skyframe/TargetPatternPhaseKeyTest.java (3)

56-57: Consistent update of test cases

All test cases are consistently updated to include the new buildRuleFilter parameter.

Also applies to: 66-67, 76-77, 86-87, 96-97, 106-107, 116-117, 126-127, 136-137, 145-146


156-157: Helper method correctly updated

The helper method is properly updated to include the new parameter and pass it to the TargetPatternPhaseValue.key method.

Also applies to: 172-173


180-181: Simplified helper method updated

The simplified helper method is correctly modified to include an empty list for the buildRuleFilter parameter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants