SeineAI / SeineSailor

Help developers navigating through the codebase smoothly
MIT License
4 stars 7 forks source link

Handle more event types #7

Open wenboown opened 5 months ago

wenboown commented 5 months ago

our current main.py has a condition check:

https://github.com/SeineAI/SeineSailor/blob/19e02192e9eaedaa4e8fc7a410467a547b4f253b/app/main.py#L62-L67

it restricted the action to only work on 3 types of events. But we want to work with all the events in the workflow yaml: https://github.com/SeineAI/SeineSailor/blob/19e02192e9eaedaa4e8fc7a410467a547b4f253b/.github/workflows/llm-review.yml#L9-L47

can the code_review and handle_review_comment function handle all of them? do we need to write some new functions?

wenboown commented 5 months ago

GPT4 suggests:

Based on the diverse range of GitHub event types you want to handle and the specific conditions in your YAML configuration, it's clear that your current main.py setup needs to be expanded to cover more scenarios. The code_review and handle_review_comment functions are specific to pull request-related events and wouldn't appropriately handle other types of events like issues, discussions, or comments on these.

Event Handling Strategy

  1. Expand Main Script: Modify main.py to handle different types of GitHub events, routing to the appropriate functions based on the event type.
  2. Create Event-Specific Functions: Develop new functions to handle the logic specific to issues, discussions, and various types of comments.

Suggested Modifications in main.py

Here’s a possible expansion for main.py to handle different events:

import os
import asyncio
from context import light_bot, heavy_bot, options, prompts

async def main():
    event_name = os.getenv("GITHUB_EVENT_NAME")

    if event_name in ["pull_request", "pull_request_target"]:
        # Handle pull request events
        await code_review(light_bot, heavy_bot, options, prompts)

    elif event_name == "pull_request_review_comment":
        # Handle pull request review comment events
        await handle_review_comment(heavy_bot, options, prompts)

    elif event_name in ["issue_comment", "discussion_comment"]:
        # Handle comments on issues and discussions
        await handle_general_comment(heavy_bot, options, prompts)

    elif event_name in ["issues", "discussion"]:
        # Handle issues and discussions
        await handle_issues_and_discussions(heavy_bot, options, prompts)

    elif event_name == "pull_request_review":
        # Handle pull request review events
        await handle_pull_request_review(heavy_bot, options, prompts)

    else:
        print(f"Skipped: this action does not handle {event_name} events")

asyncio.run(main())

New Functions to Implement

  1. handle_general_comment: Handles comments on issues and discussions.

  2. handle_issues_and_discussions: Handles opening and editing of issues and discussions.

  3. handle_pull_request_review: Handles events related to pull request reviews.

Example of New Function: handle_general_comment

async def handle_general_comment(bot, options, prompts):
    # Extract data from the event payload
    comment_body = os.getenv("GITHUB_EVENT_PAYLOAD").get('comment', {}).get('body', '')
    if '@SeineSailor' in comment_body:
        # Process the comment
        print("Handling a general comment...")
        response = await bot.respond_to_comment(comment_body, options, prompts)
        # Logic to post response back to GitHub

Integration and Testing

By structuring your main.py to appropriately route and handle different GitHub events, and by implementing specific functions for each event type, you can ensure that your GitHub Action is robust, flexible, and maintainable.

wenboown commented 5 months ago

for pull_request/pull_request_target, pull_request_review_comment, pull_request_review, what will be different in the payload that github action provides? and what kind of operations we can conduct differently that require us to use different functions to handle them?

wenboown commented 5 months ago

ChatGPT4:

When GitHub Actions processes different types of events related to pull requests, the payload provided for each event type varies slightly. These differences primarily relate to the specifics of the event context—such as whether a comment, a review, or the pull request itself is the focus. Understanding these differences is crucial for designing functions that correctly handle each type of event.

Differences in Event Payloads

  1. pull_request / pull_request_target:

    • Payload Details: Includes comprehensive details about the pull request, such as its number, state (open, closed), the pull request body, title, the commits associated with it, and more.
    • Operations: Actions typically performed include checking the pull request for compliance with project standards, running automated tests, linting, code analysis, merging, or closing.
  2. pull_request_review:

    • Payload Details: Focuses on a specific review submitted to a pull request. Includes details about the review itself, the state of the review (submitted, edited, dismissed), and the reviewer.
    • Operations: Common actions include analyzing the content of the review, perhaps triggering further actions based on approval status, comment content in the review, or dismissing outdated reviews.
  3. pull_request_review_comment:

    • Payload Details: Specifically deals with comments on the code diffs in a pull request review. Includes information about the individual comment, the part of the code it refers to, and details about the commit to which it was attached.
    • Operations: Often used to handle specific feedback on code lines, such as responding to questions, making requested changes, or further clarifications.

Handling Different Operations

Given these payload distinctions, operations can be tailored to the context of each event type:

Example Code Adjustment for Pull Request Review

Here's a basic outline of what a function handling pull request reviews might look like:

async def handle_pull_request_review(bot, options, prompts):
    review_body = os.getenv("GITHUB_EVENT_PAYLOAD").get('review', {}).get('body', '')
    review_state = os.getenv("GITHUB_EVENT_PAYLOAD").get('review', {}).get('state', '')

    if review_state == 'approved':
        # Maybe trigger deployment or further integration tests
        print("Review approved. Triggering deployment...")
        # (Deployment logic here)
    elif review_state in ['changes_requested', 'commented']:
        # Handle requested changes or review comments
        print("Handling review feedback...")
        # (Feedback handling logic here)

Conclusion

Each function you create to handle these different types of events should be tailored to the specific data and potential actions relevant to that event. It's important to structure your code to cleanly separate concerns, making it easier to maintain and scale as your project's GitHub Actions become more complex.