Create GitHub Action for review (Check if works)

[go-zen-chu]

Why

• Same as #6

What

• action ci : check golang build & lint & test
• action check-pr : check the content of pr

QA, Evidence

• [x] Check if CI works ok → https://github.com/go-zen-chu/aictl/actions/runs/10991204140/job/30513083939

---

Code Review for .github/workflows/check-pr.yml

Overall Structure

• The workflow appears to be comprehensively structured to handle pull request checks and runs on specific events (opened and synchronize).

Code Readability

1. Naming Conventions:

   • The workflow name (check-pr) is descriptive, giving a clear purpose of the file.
   • Job names (check-aictl) could provide more context about what aspect of the PR is being checked (e.g., aictl-review or AI-Code-Review).

2. Comments:

   • The comments are helpful and clarify the purpose of each step. Additional inline comments for some steps (such as explaining why fetch-depth is important) would be beneficial for future maintainability.

Specific Sections

Job Definitions

jobs:
  check-aictl:

• Consider making job names more specific to enhance understanding for other developers or users.

Steps

1. Get Number of Commits:

   - name: Get number of commit to of pr commits for checkout
       run: echo "fetch_depth=$(( commits + 1 ))" >> $GITHUB_ENV

   • The step name contains a typo ("commit to of"). It should be revised to something like "Get number of commits for fetch depth".
   • Make sure to validate that commits is properly fetched from the context.

2. Git Checkout:

   - name: Git checkout until fetch-depth
       uses: actions/checkout@v4
       with:
         fetch-depth: ${{ env.fetch_depth }}
         ref: ${{ github.event.pull_request.head.sha }}

   • This step effectively sets up the environment for the PR review process. It’s good use of the actions/checkout with dynamic fetch depth.

3. Fetch Base Branch:

   - name: Fetch base branch as origin
       run: git fetch origin ${{ github.event.pull_request.base.ref }}

   • This part efficiently ensures that the base branch is available for comparison.

4. Get Diff:

   - name: Get the diff between PR and origin branch

   • Good job checking for differences and outputting them.
   • The use of tr and sed helps format the outputs correctly. However, ensure that it is robust against files with spaces in their names.

5. Run AICTL Review:

   - name: Run aictl review
       id: aictl-review
       uses: ./ 
       if: steps.git-diff.outputs.diff-files != ''

   • The conditional execution based on non-empty diff is good practice.
   • Passing a query for AI review should be well defined, and it appropriately uses environmental secrets for security.

6. Comment on Pull Request:

     - run: |
         echo "aictl-review: ${{ steps.aictl-review.outputs }}"
         echo "aictl-review: ${{ steps.aictl-review.outputs.* }}"
         gh pr comment --body ${{steps.aictl-review.outputs}} "${URL}"

   • It's excellent to see output being logged, but be cautious of printing potentially sensitive outputs.
   • The use of the gh pr comment command is a good integration with GitHub CLI.

Security and Best Practices

1. Secrets Management:

   • Proper use of secrets for the OpenAI API key and GitHub token is commendable. Ensure that AICTL_OPENAI_API_KEY and GITHUB_TOKEN are correctly added in the repository settings.

2. Error Handling:

   • Consider adding error handling between critical steps to manage failures gracefully (e.g., checking if the fetch was successful or if there are any actual differences).

Conclusion

Overall, this workflow appears robust and serves its purpose well. With minor adjustments in naming, comment clarity, and safety measures around output logging, it can be optimized for better usability and maintainability. Great job implementing this automation!

[go-zen-chu]

Overall, this workflow appears robust and serves its purpose well

Thanks, AI