test: add demo file to trigger actions - #1
Conversation
🤖 AGI Engineer Analysis ResultsTotal Issues Found: 21 ✅ Safe to Auto-Fix: 10 issues DetailsThis refactored code includes a 📄 /home/runner/work/agi-engineer/agi-engineer/agent/safety_checker.py
Here is an updated version of the code incorporating some of these suggestions: """
Safety Checker - Verify fixes don't introduce regressions
"""
import subprocess
import sys
import json
from typing import Dict, List
class RegressionChecker:
"""Verify that fixes don't break anything"""
def __init__(self) -> None:
"""
Initialize the RegressionChecker object.
Sets the pre_fix_scan and post_fix_scan attributes to None.
"""
self.pre_fix_scan = None
self.post_fix_scan = None
def scan_repo(self, repo_path: str) -> List[Dict]:
"""
Scan repository and return all issues.
Args:
repo_path (str): The path to the repository to scan.
Returns:
List[Dict]: A list of dictionaries representing the issues found.
"""
cmd = [sys.executable, "-m", "ruff", "check", ".", "--output-format", "json", "--exit-zero"]
try:
result = subprocess.run(cmd, cwd=repo_path, capture_output=True, text=True)
result.check_returncode() # Raise CalledProcessError if returncode is non-zero
except subprocess.CalledProcessError as e:
# Handle the case where the subprocess fails
print(f"Error running subprocess: {e}")
return []
if not result.stdout.strip():
return []
try:
data = json.loads(result.stdout)
return data
except json.JSONDecodeError as e:
# Handle the case where the JSON parsing fails
print(f"Error parsing JSON: {e}")
return []
def record_before(self, repo_path: str) -> Dict:
"""
Record issues before fixes.
Args:
repo_path (str): The path to the
📄 /home/runner/work/agi-engineer/agi-engineer/agi_engineer_v3.py
Here are the suggestions for improving the provided Python code:
1. **Use a more descriptive variable name instead of `text`** (line 15): The variable `text` in the `print_header` function could be renamed to something like `header_text` to make its purpose clearer.
2. **Add a docstring to the `print_section` function** (line 20): The `print_section` function is missing a docstring that explains its purpose and parameters.
3. **Consider using a constant for the header and section separator characters** (lines 16-17 and 22-23): Instead of hard-coding the header and section separator characters, consider defining constants at the top of the file to make the code more readable and maintainable.
4. **Use type hints for the `issues` parameter in the `display_classification` function** (line 28): The `issues` parameter should have a type hint, such as `list[dict]`, to indicate the expected type of data.
5. **Consider using a more descriptive variable name instead of `summary`** (line 30): The variable `summary` could be renamed to something like `classification_summary` to make its purpose clearer.
6. **Add a docstring to the `display_classification` function** (line 28): The `display_classification` function could benefit from a docstring that explains its purpose, parameters, and return values.
7. **Use a more descriptive variable name instead of `by_code`** (lines 37 and 45): The variable `by_code` could be renamed to something like `issue_count_by_code` to make its purpose clearer.
8. **Consider using a dictionary comprehension instead of a for loop to create the `by_code` dictionary** (lines 38-41): The code that creates the `by_code` dictionary could be simplified using a dictionary comprehension.
9. **Use a more descriptive variable name instead of `code`** (lines 38 and 45): The variable `code` could be renamed to something like `issue_code` to make its purpose clearer.
10. **Consider using a constant for the safety category names** (lines 34-35 and 43-44): Instead of hard-coding the safety category names, consider defining constants at the top of the file to make the code more readable and maintainable.
11. **Add error handling to the `display_classification` function** (line 28): The `display_classification` function should include error handling to handle potential exceptions that may occur during execution.
12. **Consider using a logging library instead of print statements** (lines 16-17, 22-23, 31-32, etc.): Instead of using print statements to output messages, consider using a logging library like the `logging` module to make the code more flexible and configurable.
Here's an updated version of the code incorporating some of these suggestions:
```python
import os
import sys
import argparse
import shutil
import tempfile
import subprocess
import json
import logging
# Define constants for header and section separator characters
HEADER_SEPARATOR = "═" * 60
SECTION_SEPARATOR = "─" * 60
# Define constants for safety category names
SAFE_CATEGORY = "SAFE TO AUTO-FIX"
RISKY_CATEGORY = "NEEDS REVIEW"
# Set up logging
logging.basicConfig(level=logging.INFO)
def print_header(header_text: str) -> None:
"""Print formatted header"""
logging.info(f"\n🤖 {header_text}")
logging.info(HEADER_SEPARATOR)
def print_section(title: str) -> None:
"""Print section header"""
logging.info(f"\n{title}")
logging.info(SECTION_SEPARATOR)
def display_classification(classifier: RuleClassifier, issues: list[dict]) -> None:
"""Display issues grouped by safety category"""
try:
classification_summary = classifier.get_summary(issues)
grouped = classification_summary['grouped']
print_section("📋 ISSUE CLASSIFICATION")
# Safe rules
if grouped['safe']:
logging.info(f"\n✅ {SAFE_CATEGORY} ({len(grouped['safe'])} issues)")
issue_count_by_code: dict[str, int] = {}
for issue in grouped['safe']:
issue_code = issue['code']
issue_count_by_code[issue_code] = issue_count_by_code.get(issue_code, 0) + 1
for issue_code, count in sorted(issue_count_by_code.items()):
rule_info = classifier.classify(issue_code)
logging.info(f" • {issue_code}: {rule_info['name']} ({count})")
# Risky rules
if grouped['risky']:
logging.info(f"\n⚠️ {RISKY_CATEGORY} ({len(grouped['risky'])} issues)")
issue_count_by_code: dict[str, int] = {}
for issue in grouped['risky']:
issue_code
✨ Analysis complete!Run locally: |
1 participant
No description provided.