docs: add diff rule presets for threading guardrails #29
Conversation
Summary of ChangesHello @naaa760, I'm Gemini Code Assist1! 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 enhances the documentation by providing practical, ready-to-use diff-aware rule presets for Python threading guardrails. It aims to simplify the adoption of best practices for threading by offering pre-configured rules and clear instructions on how to implement them, even when facing potential UI limitations in rule application platforms. Highlights
Using Gemini Code AssistThe 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
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 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 👍 and 👎 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. Footnotes
|
|
Codecov Report✅ All modified and coverable lines are covered by tests. ❌ Your project status has failed because the head coverage (32.0%) is below the target coverage (80.0%). You can increase the head coverage or adjust the target coverage. @@ Coverage Diff @@
## main #29 +/- ##
=======================================
+ Coverage 24.7% 32.0% +7.2%
=======================================
Files 79 85 +6
Lines 4497 4993 +496
=======================================
+ Hits 1115 1601 +486
- Misses 3382 3392 +10 Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a valuable set of preset rules for enforcing Python threading best practices, along with corresponding documentation. This is a great initiative. However, the current implementation of several rules in docs/assets/threading-guardrails.yaml is likely to produce a high volume of false positives, which could make them impractical. Specifically, the rules using require_patterns are too broad as they apply to all modified Python files. Additionally, the regular expression for limiting max_workers is incomplete. I have provided specific comments and suggestions to address these issues and improve the usability of these presets.
| require_patterns: | ||
| - "concurrent\\.futures\\.ThreadPoolExecutor" |
There was a problem hiding this comment.
The require_patterns clause makes this rule overly broad. It will enforce the presence of concurrent.futures.ThreadPoolExecutor in any modified Python file, even those unrelated to threading, leading to a high number of false positives. To achieve the goal of preferring ThreadPoolExecutor over threading.Thread, simply forbidding threading.Thread is a more effective and less noisy approach. Consider removing the require_patterns block to make the rule more targeted and practical.
| require_patterns: | ||
| - "threading\\.Lock" |
There was a problem hiding this comment.
This rule is too broad and will likely create a lot of noise. It requires threading.Lock to be present in any modified Python file, regardless of whether it uses threading. This will trigger for any change, such as fixing a typo in a comment in a file that doesn't use threading. For this rule to be effective, it should be conditional on the presence of threading code (e.g., ThreadPoolExecutor). In its current form, this rule is impractical due to the high potential for false positives.
| require_patterns: | ||
| - "queue\\.Queue" |
There was a problem hiding this comment.
Similar to the rule for threading.Lock, this rule is too broad. It requires queue.Queue in every modified Python file, which will lead to many false positives. This check should ideally be triggered only when threading is being used in the file to be useful and avoid excessive noise.
| parameters: | ||
| file_patterns: ["**/*.py"] | ||
| forbidden_patterns: | ||
| - "ThreadPoolExecutor\\(max_workers\\s*=\\s*(1[1-9]|[2-9][0-9])" |
There was a problem hiding this comment.
The regular expression to detect max_workers greater than 10 is incomplete. It currently matches values from 11 to 99, but it will miss any value of 100 or greater. To correctly match all integers greater than 10, the regex should be updated to cover numbers with three or more digits.
- "ThreadPoolExecutor\\(max_workers\\s*=\\s*(1[1-9]|[2-9]\\d|\\d{3,})"
3 participants
What
Add a ready-to-use threading guardrails preset (docs/assets/threading-guardrails.yaml) using diff-aware validators (file_patterns + require/forbidden regex).
Add a short guide (docs/getting-started/diff-rule-presets.md) explaining how to apply these rules even if the watchflow.dev form blocks diff rules.
Link the guide in the MkDocs nav.
Why
Testing