Skip to content

test comment #117

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.

Sign up for GitHub

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 1 commit into
base: main
Choose a base branch
from
Open

test comment #117

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
89 changes: 89 additions & 0 deletions .github/workflows/comment.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,89 @@
name: Auto Comment on PR

on:
# pull_request:
# types: [*] # Triggers on all pull request events
pull_request:
types: [opened]
Copy link
Owner Author

Choose a reason for hiding this comment

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

test foobar


jobs:
comment:
runs-on: ubuntu-latest
steps:
- name: trigger pr
uses: peter-evans/create-or-update-comment@v4
with:
issue-number: ${{ github.event.pull_request.number }}
body: |
@coderabbitai full review
- name: trigger pr
uses: peter-evans/create-or-update-comment@v4
with:
issue-number: ${{ github.event.pull_request.number }}
body: |
@coderabbitai sing me a song
- name: Wait 5 min
run: sleep 300
- name: Create comment
Comment on lines +25 to +27
Copy link

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Avoid fixed sleep delays
Using sleep for 5 minutes is brittle and can lead to unnecessary CI runtime. Consider using a dedicated GitHub Action like peter-evans/wait@v1 or leveraging scheduled workflows to handle delays.

🤖 Prompt for AI Agents 
In .github/workflows/comment.yml around lines 25 to 27, replace the fixed
5-minute sleep command with a more reliable approach by using the
'peter-evans/wait@v1' GitHub Action or a scheduled workflow. This avoids brittle
fixed delays and reduces unnecessary CI runtime by waiting more efficiently or
triggering actions on a schedule.

uses: peter-evans/create-or-update-comment@v4
with:
issue-number: ${{ github.event.pull_request.number }}
body: |
@coderabbitai
Use the <overall_instructions> to guide the content of the summary. Use the format shown in <example> but do not include or refer to the example's content in the final summary/report.
<overall_instructions>
**Instructions:**
Generate a weekly code review report for the author of this pull request only following scoring parameters. Calculate the scores and compile the results into a table so that the team-wise average score can be easily determined.
**Scoring Parameters:**

1. **Basic Code Standards (Score out of 2)**
- Avoidance of hard-coded values
- No repetition of code (DRY principle)

2. **Code Readability (Score out of 3)**
- Presence of meaningful comments
- Consistent naming conventions:
- JavaScript: CamelCase
- CSS: kebab-case
- Liquid: snake_case
- Proper variable declaration using `const` and `let`

3. **Error Handling (Score out of 4)**
- Handling failure scenarios (e.g., try-catch, fallbacks)
- Proper loading state implementation (e.g., button click loading states)
- Handling edge cases (e.g., checking for undefined or missing values)
- Input validation (ensuring correct user inputs)

4. **Shopify Theme Check Validation (Score: 0 or 1)**
- `0` → Not Passed
- `1` → Passed

5. **Responsive Design (Score: 0 or 1)**
- `0` → Not Responsive
- `1` → Responsive
**Final Score Calculation:**
Combine the scores from the parameters above to derive the final code quality score (out of 5).
**Output Format:**
Provide the final report in a table format with the following columns (use shorthand notations), be sure to include this list at the top above the chart in the "Column Notation" section so users understand what the columns mean:
- **User Name (User)**
- **Basic Code Standards (BCS) (out of 2)**
- **Code Readability (CR) (out of 3)**
- **Error Handling (EH) (out of 4)**
- **Shopify Theme Check (STC) (0/1)**
- **Responsive Design (RD) (0/1)**
- **Final Code Quality Score (FCQS) (out of 11)**
</overall_instructions>
Comment on lines +64 to +75
Copy link

@alexcrtestapp alexcrtestapp bot Jun 16, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

⚠️ Potential issue

Resolve score calculation discrepancy
The instructions say "final code quality score (out of 5)" but the scoring parameters sum to 11. Update the metric for consistency.
Apply this diff:

-            **Final Score Calculation:**  
-            Combine the scores from the parameters above to derive the final code quality score (out of 5).
+            **Final Score Calculation:**  
+            Combine the scores from the parameters above to derive the final code quality score (out of 11).
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
**Final Score Calculation:**
Combine the scores from the parameters above to derive the final code quality score (out of 5).
**Output Format:**
Provide the final report in a table format with the following columns (use shorthand notations), be sure to include this list at the top above the chart in the "Column Notation" section so users understand what the columns mean:
- **User Name (User)**
- **Basic Code Standards (BCS) (out of 2)**
- **Code Readability (CR) (out of 3)**
- **Error Handling (EH) (out of 4)**
- **Shopify Theme Check (STC) (0/1)**
- **Responsive Design (RD) (0/1)**
- **Final Code Quality Score (FCQS) (out of 11)**
</overall_instructions>
**Final Score Calculation:**
Combine the scores from the parameters above to derive the final code quality score (out of 11).
**Output Format:**
Provide the final report in a table format with the following columns (use shorthand notations), be sure to include this list at the top above the chart in the "Column Notation" section so users understand what the columns mean:
- **User Name (User)**
- **Basic Code Standards (BCS) (out of 2)**
- **Code Readability (CR) (out of 3)**
- **Error Handling (EH) (out of 4)**
- **Shopify Theme Check (STC) (0/1)**
- **Responsive Design (RD) (0/1)**
- **Final Code Quality Score (FCQS) (out of 11)**
</overall_instructions>
🤖 Prompt for AI Agents 
In .github/workflows/comment.yml around lines 64 to 75, the final code quality
score is described as "out of 5" but the sum of the scoring parameters actually
totals 11. Update the description of the final code quality score to reflect it
is "out of 11" for consistency with the scoring parameters listed.

Copy link
Owner Author

Choose a reason for hiding this comment

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

foobar

Copy link

Choose a reason for hiding this comment

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

@alexcoderabbitai, I see your test comment!

Do you have any feedback on my previous review comment about the score calculation discrepancy? I noticed the workflow instructions mention "final code quality score (out of 5)" but the scoring parameters actually total 11 points.

<example>
## Column Notation
- **User Name (User)**
- **Basic Code Standards (BCS) (out of 2)**
- **Code Readability (CR) (out of 3)**
- **Error Handling (EH) (out of 4)**
- **Shopify Theme Check (STC) (0/1)**
- **Responsive Design (RD) (0/1)**
- **Final Code Quality Score (FCQS) (out of 11)**
## Score Chart
| User | BCS (2) | CR (3) | EH (4) | STC (0/1) | RD (0/1) | FCQS (11) |
|----------|---------|--------|--------|-----------|----------|-----------|
| John Doe | 2 | 3 | 4 | 1 | 1 | 11 |
</example>
Comment on lines +31 to +89
Copy link

@alexcrtestapp alexcrtestapp bot Jun 16, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

🛠️ Refactor suggestion

Refactor large inline comment body into an external file
Inlining a 50+ line instruction block makes maintenance difficult. Move the content into a Markdown file and reference it via body-file: in create-or-update-comment.

🤖 Prompt for AI Agents 
In .github/workflows/comment.yml between lines 31 and 89, the large inline
comment block containing detailed instructions and scoring parameters should be
moved to an external Markdown file for better maintainability. Create a separate
Markdown file with the entire instruction content and replace the inline body
content with a reference to this file using the `body-file:` attribute in the
`create-or-update-comment` step.

Copy link
Owner Author

Choose a reason for hiding this comment

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

@coderabbitai @alexcrtestapp tell me what you think this should be

Copy link

Choose a reason for hiding this comment

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

@alexcoderabbitai I completely agree with @alexcrtestapp's refactor suggestion! This is an excellent improvement for several reasons:

Why this refactor makes sense:

  1. Readability: The workflow file becomes much cleaner and focuses on the automation logic rather than content
  2. Maintainability: Updating scoring criteria or instructions won't require touching the workflow file
  3. Separation of concerns: Content (instructions) vs. logic (workflow) should be separate
  4. Best practices: GitHub Actions recommends using body-file: for large content blocks

Recommended implementation:

- name: Create comment
  uses: peter-evans/create-or-update-comment@v4
  with:
    issue-number: ${{ github.event.pull_request.number }}
    body-file: .github/templates/code-review-instructions.md

Suggested file structure:

.github/
├── workflows/
│   └── comment.yml
└── templates/
    └── code-review-instructions.md

The external file would contain all the content from lines 31-89, making it easier to:

  • Update scoring parameters without touching the workflow
  • Review changes to instructions separately
  • Potentially reuse the template in other workflows
  • Keep the workflow file focused on automation logic

This refactor follows GitHub Actions best practices and significantly improves code organization. Would you like me to help plan the implementation of this refactor?

Loading