feat: implement quadric error metric mesh simplification #596
Workflow file for this run
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| name: opencode | |
| on: | |
| pull_request: | |
| types: [opened, synchronize, reopened, ready_for_review] | |
| workflow_dispatch: | |
| inputs: | |
| pr_number: | |
| description: 'PR number to review (triggered by test-writer)' | |
| required: true | |
| type: number | |
| head_sha: | |
| description: 'Head SHA of the PR to review' | |
| required: true | |
| type: string | |
| concurrency: | |
| group: ${{ github.workflow }}-${{ github.event.pull_request.number || inputs.pr_number }} | |
| cancel-in-progress: true | |
| jobs: | |
| opencode: | |
| if: > | |
| (github.event_name == 'pull_request' && github.event.pull_request.draft == false && !startsWith(github.event.pull_request.head.ref, 'opencode/schedule-')) || | |
| github.event_name == 'workflow_dispatch' | |
| runs-on: blacksmith-2vcpu-ubuntu-2404 | |
| timeout-minutes: 30 | |
| permissions: | |
| id-token: write | |
| contents: write | |
| pull-requests: write | |
| issues: write | |
| steps: | |
| - name: Resolve PR context | |
| id: resolve-pr | |
| run: | | |
| if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then | |
| echo "pr_number=${{ inputs.pr_number }}" >> "$GITHUB_OUTPUT" | |
| echo "pr_head_sha=${{ inputs.head_sha }}" >> "$GITHUB_OUTPUT" | |
| else | |
| echo "pr_number=${{ github.event.pull_request.number }}" >> "$GITHUB_OUTPUT" | |
| echo "pr_head_sha=${{ github.event.pull_request.head.sha }}" >> "$GITHUB_OUTPUT" | |
| fi | |
| - name: Checkout repository | |
| uses: actions/checkout@v4 | |
| with: | |
| ref: ${{ steps.resolve-pr.outputs.pr_head_sha }} | |
| fetch-depth: 0 | |
| token: ${{ github.token }} | |
| - name: Configure git | |
| run: | | |
| git config user.name "github-actions[bot]" | |
| git config user.email "github-actions[bot]@users.noreply.github.com" | |
| - name: Fetch previous opencode reviews | |
| id: previous-reviews | |
| run: | | |
| PR_NUMBER="${{ steps.resolve-pr.outputs.pr_number }}" | |
| echo "Fetching previous automated reviews..." | |
| gh api /repos/${{ github.repository }}/pulls/${PR_NUMBER}/reviews \ | |
| --jq '.[] | select(.user.login == "opencode-agent[bot]") | {body: .body, submitted_at: .submitted_at}' > /tmp/opencode_reviews.json 2>/dev/null || echo "[]" > /tmp/opencode_reviews.json | |
| gh api /repos/${{ github.repository }}/pulls/${PR_NUMBER}/comments \ | |
| --jq '.[] | select(.user.login == "opencode-agent[bot]") | {body: .body, path: .path, line: .line, created_at: .created_at}' > /tmp/opencode_comments.json 2>/dev/null || echo "[]" > /tmp/opencode_comments.json | |
| REVIEW_CONTENT="## Previous Automated Reviews from opencode-agent:\n\n" | |
| if [ -s /tmp/opencode_reviews.json ] && [ "$(cat /tmp/opencode_reviews.json)" != "[]" ]; then | |
| while IFS= read -r review; do | |
| if [ -n "$review" ] && [ "$review" != "null" ]; then | |
| body=$(echo "$review" | jq -r '.body // empty') | |
| date=$(echo "$review" | jq -r '.submitted_at // empty') | |
| if [ -n "$body" ] && [ "$body" != "null" ]; then | |
| REVIEW_CONTENT="${REVIEW_CONTENT}### Review from ${date}\n${body}\n\n---\n\n" | |
| fi | |
| fi | |
| done < /tmp/opencode_reviews.json | |
| else | |
| REVIEW_CONTENT="${REVIEW_CONTENT}No previous automated reviews found.\n" | |
| fi | |
| { | |
| echo "PREVIOUS_REVIEWS<<EOF" | |
| printf '%s\n' "$REVIEW_CONTENT" | |
| echo "EOF" | |
| } >> "$GITHUB_ENV" | |
| echo "Previous reviews fetched and formatted for context" | |
| env: | |
| GH_TOKEN: ${{ github.token }} | |
| - name: Setup Nix | |
| uses: ./.github/actions/setup-nix | |
| - name: Prepare opencode cache | |
| run: mkdir -p /tmp/opencode-cache && echo "XDG_CACHE_HOME=/tmp/opencode-cache" >> "$GITHUB_ENV" | |
| - name: Run opencode | |
| uses: anomalyco/opencode/github@latest | |
| env: | |
| GITHUB_TOKEN: ${{ github.token }} | |
| GH_TOKEN: ${{ github.token }} | |
| KIMI_API_KEY: ${{ secrets.KIMI_API_KEY }} | |
| with: | |
| model: kimi-for-coding/k2p5 | |
| use_github_token: true | |
| prompt: | | |
| You are reviewing a pull request for the ZigCraft repository. | |
| **PR to review:** #${{ steps.resolve-pr.outputs.pr_number }} | |
| Use `gh pr diff ${{ steps.resolve-pr.outputs.pr_number }}` and `gh pr view ${{ steps.resolve-pr.outputs.pr_number }}` to examine the changes. | |
| Give full review coverage to PRs created by the automated test writer, especially PRs labeled `automated-test`, and verify whether any linked issues are fully addressed. | |
| ZigCraft is a high-performance Minecraft-style voxel engine built with Zig, SDL3, and Vulkan. It uses Nix for dependency management, a custom RHI (Render Hardware Interface) abstraction layer, and a multithreaded job system for world generation and meshing. | |
| **Tech Stack:** | |
| - Zig 0.14+ with strict memory management (explicit allocators, defer/errdefer) | |
| - SDL3 for windowing and input | |
| - Vulkan for rendering (only backend, via RHI abstraction) | |
| - Nix for reproducible builds (`nix develop --command zig build`) | |
| - GLSL shaders validated via glslangValidator | |
| **Build Commands:** | |
| - `nix develop --command zig build test` - Unit tests + shader validation | |
| - `nix develop --command zig build test -- --test-filter "test name"` - Single test | |
| - `nix develop --command zig fmt src/` - Format code | |
| **Prioritize review attention on:** | |
| - RHI/Vulkan correctness (buffer/texture handles, pipeline state, synchronization) | |
| - Memory safety (allocator usage, defer cleanup, ArrayListUnmanaged patterns) | |
| - Threading/concurrency (JobSystem usage, chunk pin/unpin, mutex protection) | |
| - GPU resource lifecycle (creation, destruction, double-buffering with MAX_FRAMES_IN_FLIGHT) | |
| - Packed struct correctness for GPU data (PackedLight, Vertex) | |
| - Coordinate system correctness (world vs chunk vs local, worldToChunk/worldToLocal) | |
| - Shader uniform naming (must match RHI exactly) | |
| ${{ env.PREVIOUS_REVIEWS }} | |
| --- | |
| **YOUR TASK:** Analyze the CURRENT code changes and previous reviews above, then output your review in the following STRICT STRUCTURE: | |
| **CRITICAL INSTRUCTIONS:** | |
| 1. **CHECK PREVIOUS ISSUES FIRST:** Look at the "Previous Automated Reviews" section above. For each issue previously reported (Critical, High, Medium, Low), verify if it still exists in the current code. | |
| 2. **ACKNOWLEDGE FIXES:** If a previously reported issue has been fixed, state "✅ **[FIXED]** Previous issue: [brief description]" in the appropriate section. | |
| 3. **ONLY REPORT NEW/UNRESOLVED ISSUES:** Do NOT re-report issues that have already been fixed. Only report issues that are still present in the current code. | |
| 4. **TRACK CHANGES:** If an issue was reported in a previous review but the code has changed, verify the new code and report the issue with updated file:line references if it still exists. | |
| --- | |
| ## 📋 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) | |
| **IMPORTANT:** Check previous reviews first. If critical issues were reported before, verify if they're fixed. If fixed, say "✅ All previously reported critical issues have been resolved." | |
| Only report NEW critical 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) | |
| Same approach as Critical - check previous reviews first, acknowledge fixes, only report unresolved issues. | |
| Same format as Critical, but with **[HIGH]** prefix. | |
| ## 💡 Medium Priority Issues (Nice to Fix) | |
| Same approach - verify previous reports, acknowledge fixes, report only still-present issues. | |
| Same format, with **[MEDIUM]** prefix. | |
| ## ℹ️ Low Priority Suggestions (Optional) | |
| Same approach. | |
| 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. **MOST IMPORTANT:** Always check previous reviews and verify if issues are fixed before reporting them again | |
| 2. Acknowledge fixes explicitly with ✅ **[FIXED]** markers | |
| 3. Check the PR description for linked issues ("Fixes #123", "Closes #456", etc.) and verify the implementation | |
| 4. Be extremely specific with file paths and line numbers | |
| 5. Confidence scores should reflect how certain you are - use "Low" when unsure | |
| 6. If you have nothing meaningful to add to a section, write "None identified" instead of omitting it | |
| 7. Always provide actionable fixes, never just complaints |