action.yaml

name: Gitea Code Review
description: A GitHub Action that uses OpenAI to review code in pull request.
inputs:
  PROGRAMMING_LANGUAGE:
    description: 'The programming language used in the GitHub repository. If not provided, the detected programming language will be used.'
    default: ''
  FULL_REVIEW_COMMENT:
    description: 'The comment to trigger a code review for the pull request.'
    default: 'openai'
  REVIEW_COMMENT_PREFIX:
    description: 'The comment prefix to trigger a code review with the comment content.'
    default: 'openai:'
  OPENAI_TOKEN:
    description: 'The API token for the OpenAI API.'
    required: true
  GITHUB_TOKEN:
    description: 'The API token for the Github API.'
    required: true
  GITHUB_BASE_URL:
    description: 'The base URL for the GitHub API.'
  MAX_CODE_LENGTH:
    description: 'The maximum code length for the pull request to be sent to OpenAI.'
    default: 6000
    type: int
  SOURCE_AT:
    description: 'Where is the source code located'
    default: 'github'
  PROMPT_TEMPLATE:
    description: 'The template for the FULL_REVIEW_COMMENT prompt.'
    default: 'Your task is to act as a code reviewer and review a pull request by summarizing the changes made, identifying potential issues related to logic and runtime, and creating a bullet list of action items needed before the change can be approved. The output should focus on items mentioned in the given code review checklist.
Instructions:
- Review the output of git diff for the pull request
- Identify potential issues related to logic and runtime
- You will only mention the checklist item when it violates the check. If there is nothing found you wont need to mention about checklist. Instead you can say "Raktbeej couldnt find any failed check."
- Output as a markdown document, with the following sections:
    ### Overall Summary:
      - Each bullet point should provide the summary on what this Pull request does. Each point shouldnt exceed more than 14 words.
    ### Issues & Action Items:
      - Title of the check that it violated and a one liner guideline to user on how it can be fixed.
      - TODO List with the name of the file, violating policy and line no where you think it was violated.
    ### APPROVE / DISAPPROVE this PR:
      - Tell me if this Pull request can be approved or not. if its disapproved just mention it clearly to fix the problem and raise another pull request. If its approved then appreciate everyone and say it can be approved.
- If there are no issues, output "None"
- If there are no action items, output "None"
- Create a bullet list of action items needed before the change can be approved
- The response sentences are no longer than 16 words each
- Keep the response sentences as short as possible
- Below code is for laravel framework then you need to check for N+1 query detection in the pull request. If you find for potential N+1 problems you will add it to your response in file name and function.
- Check for any access to a relationship that is not eager-loaded either in the body of the current function (using with() or load()) or in the model itself (using the $with property).
- Check for any call to DB functions in the loop such as DB::table()
- Check for any call to static Model functions in the loop such as Product::find()
- Check for any call to Model functions in the loop such as $product->save()
- Check if a pull request shows push an HTTP resource class you will check if pull request code used the whenLoaded() helper provided by Laravel. It is a great way to avoid N+1 and performance issues.
- Check if a pull request code push a migration we check if it has added any kind of index to new columns. The full path has to include migration in order to trigger this check.
- Check if a pull request code push a migration we check if it has a down method and it is not empty. The full path has to include migration in order to trigger this check.
- Check if a pull request code create a new column that ends with _id you will warn if a pull request code forgot to add a foreign key to that column.
- Check if a pull request code push an HTTP request we check if it has an authorize method and it is not return true. The filename must end with Request.php or the full path has to include Requests in order to trigger this check.
- Check if a pull request code push a controller we check if it uses any kind of validator. Usually, it is a better idea to move this logic to a Request class. The filename must end with Controller.php or the full path has to include Controllers in order to trigger this check.
- Check if a pull request code added a new key to one of the config file we check if a pull request code also included it in the .env.example file
- Check if a pull request code contains an env() call anywhere outside of a config file it needs to be warn. It is a best practice to only use env() in config files.
- Check if a pull request code contains a Cache::rememberForever() call It needs to be warn.
- Check for Validation with reference to Request that has non nullable database table column in migration.  
- Check for Incorrect dependencies as there are different layers in every Laravel application. Layers such as: HTTP, Business Logic, Database, etc. Each layer has its own dependencies. For example, the database layer should not depend on the HTTP layer. If it does, it should warn.
    Here are what counts as an incorrect dependency:
    - This class -> Depends on these
    - Model -> HTTP, Job, Command, Checker
    - Job -> HTTP
    - Command -> HTTP
    - Mail/Notification -> HTTP, Job, Command
    - Service -> HTTP
    - Repository -> HTTP, Job, Command
- Check for Complex data object as there are some typical classes that should not contain too much business logic since their main purpose is to hold data. These classes are:
  - Resources
  - Livewire
  - Requests
  - DataTransferObjects (DTO)
  - Value Objects
  - Mail
  - Notification
  - Event
  - Listener
- Check for cyclomatic complexity if a class that contains too much business logic, it needs to be warn. "Too much" means that the cyclomatic complexity of the class is larger than 3.
- Check for pull request to make sure that coder has followed principles of Single Responsibility Principle (SRP) and Dont Repeat Yourself (DRY) principle. If not explain where the user needs to make changes.
- Check for naming conventions, if a pull request code is violating the naming convention it needs to be warn.
- Check for code complexity, if the pull request code is violating in maintaining the code complexity level.
- Check for Error handling in the pull request, if pull request code has a proper error handling in the below scenarios.
    - Are all error scenarios covered in the code?
    - Are the error messages clear and helpful?
    - Is the code handling errors gracefully?
- Check for Security
  - Are sensitive data and credentials stored securely?
  - Are all external libraries and packages up-to-date?
  - Is the code protected against common security vulnerabilities such as SQL injection and cross-site scripting (XSS)?
\`\`\`
${code}
\`\`\`'

  ANSWER_TEMPLATE:
    description: 'The template for the answer sent to the GitHub comment.'
    default: 'Raktbeej Code Review:

## Summary:

${answer}'
runs:
  using: 'node16'
  main: 'dist/index.js'