Skip to content

Add comprehensive test suite #23

Add comprehensive test suite

Add comprehensive test suite #23

Workflow file for this run

# ---
# id: opencode/opencode-pr
# category: opencode
# type: set
# name: OpenCode AI PR Review
# description: Automated AI-powered code review for pull requests using OpenCode
# secrets:
# - name: KIMI_API_KEY
# description: API key for OpenCode AI service
# required: true
# inputs: []
# triggers: [pull_request]
# variants:
# - name: standard
# description: Uses OpenCode GitHub Action
# ---
name: OpenCode AI PR Review
on:
pull_request:
types: [opened, synchronize, reopened, ready_for_review]
jobs:
opencode:
# Don't run on draft PRs; do run when they become ready_for_review.
if: ${{ github.event.pull_request.draft == false }}
runs-on: ubuntu-latest
timeout-minutes: 10
permissions:
id-token: write
contents: write
pull-requests: write
issues: read
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Configure git
run: |
git config user.name "github-actions[bot]"
git config user.email "github-actions[bot]@users.noreply.github.com"
- name: Run opencode
uses: anomalyco/opencode/github@latest
env:
KIMI_API_KEY: ${{ secrets.KIMI_API_KEY }}
with:
model: kimi-for-coding/k2p5
prompt: |
You are reviewing a pull request. Analyze the code changes and output your review in the following STRICT STRUCTURE:
---
## 📋 Summary
First, check if the PR description mentions any linked issues (e.g., "Closes #123", "Fixes #456", "Resolves #789").
If linked issues are found:
- Mention the issue number(s) explicitly
- Verify the PR actually implements what the issue(s) requested
- State whether the implementation fully satisfies the issue requirements
Then provide 2-3 sentences summarizing the PR purpose, scope, and overall quality.
## 🔴 Critical Issues (Must Fix - Blocks Merge)
Only issues that could cause crashes, security vulnerabilities, data loss, or major bugs.
For each issue, use this exact format:
```
**[CRITICAL]** `File:Line` - Issue Title
**Confidence:** High|Medium|Low (how sure you are this is a real problem)
**Description:** Clear explanation of the issue
**Impact:** What could go wrong if merged
**Suggested Fix:** Specific code changes needed
```
## ⚠️ High Priority Issues (Should Fix)
Significant code quality issues, potential bugs, or architectural problems.
Same format as Critical, but with **[HIGH]** prefix.
## 💡 Medium Priority Issues (Nice to Fix)
Style issues, minor optimizations, or code clarity improvements.
Same format, with **[MEDIUM]** prefix.
## ℹ️ Low Priority Suggestions (Optional)
Minor suggestions, documentation improvements, or subjective preferences.
Same format, with **[LOW]** prefix.
## 📊 SOLID Principles Score
| Principle | Score | Notes |
|-----------|-------|-------|
| Single Responsibility | 0-10 | Brief justification |
| Open/Closed | 0-10 | Brief justification |
| Liskov Substitution | 0-10 | Brief justification |
| Interface Segregation | 0-10 | Brief justification |
| Dependency Inversion | 0-10 | Brief justification |
| **Average** | **X.X** | |
## 🎯 Final Assessment
### Overall Confidence Score: XX%
Rate your confidence in this PR being ready to merge (0-100%).
**How to interpret:**
- 0-30%: Major concerns, do not merge without significant rework
- 31-60%: Moderate concerns, several issues need addressing
- 61-80%: Minor concerns, mostly ready with some fixes
- 81-100%: High confidence, ready to merge or with trivial fixes
### Confidence Breakdown:
- **Code Quality:** XX% (how well-written is the code?)
- **Completeness:** XX% (does it fulfill requirements?)
- **Risk Level:** XX% (how risky is this change?)
- **Test Coverage:** XX% (are changes adequately tested?)
### Merge Readiness:
- [ ] All critical issues resolved
- [ ] SOLID average score >= 6.0
- [ ] Overall confidence >= 60%
- [ ] No security concerns
- [ ] Tests present and passing (if applicable)
### Verdict:
**MERGE** | **MERGE WITH FIXES** | **DO NOT MERGE**
One-sentence explanation of the verdict.
---
**Review Guidelines:**
1. Check the PR description for linked issues ("Fixes #123", "Closes #456", etc.) and verify the implementation
2. Be extremely specific with file paths and line numbers
3. Confidence scores should reflect how certain you are - use "Low" when unsure
4. If you have nothing meaningful to add to a section, write "None identified" instead of omitting it
5. Always provide actionable fixes, never just complaints