Review

The Review component is your gateway to managing code changes on GitHub directly from your Nappai dashboard. It allows you to automate the flow of code review processes by interacting with Pull Requests (PRs).

You can use this component to automatically notify team members that code is ready for review, leave feedback comments, approve changes, or request specific modifications. It serves as a bridge between your automation workflows and your GitHub repositories, ensuring that your code review processes happen exactly when and how you want them to.

How it Works

This component connects to the GitHub API to perform specific actions on Pull Requests. When you configure it, you are essentially telling GitHub what to do with a specific piece of code change.

Internally, the component identifies the correct repository and Pull Request number you specify. It then sends a secure command to GitHub to either:

• Retrieve Information: Fetch the details of a specific PR or a list of PRs based on filters (like status).
• Add Feedback: Insert a text comment into the PR discussion thread.
• Manage Reviews: Formally approve code, request changes, or add comments with a specific review status.

When the operation is complete, the component returns status information (like “Success” or “Failed”) and unique IDs for the actions taken, which you can use in later steps of your automation.

Connection & Credentials

This component requires configuring a credential in the Nappai panel before interacting with the external service:

1. Go to the Credentials section in your Nappai panel.
2. Create a new credential of the type GitHub API and fill in the required fields (GitHub Personal Access Token). Ensure this token has the repo scope to allow management of pull requests.
3. In your workflow, select the saved credential in the Credential input field of this node.

Operations

This component offers several operations that you can select based on what you need to do. You can only use one operation at a time:

• Get PR: Retrieve the detailed information of a specific Pull Request using its number.
• List PRs: Retrieve a list of Pull Requests from a repository, optionally filtering by state.
• Create PR Comment: Add a simple text comment to a Pull Request discussion thread.
• Get Review: Retrieve the details of a specific code review request or submission.
• List Reviews: Retrieve a list of reviews or comments associated with a Pull Request.
• Create Review: Perform a formal review action such as approving code, requesting changes, or adding a contextual comment.

To use the component, first select the operation you need in the “Operation” field.

Inputs

Mapping Mode

This component has a special mode called “Mapping Mode”. When you enable this mode using the toggle switch, an additional input called “Mapping Data” is activated, and each input field offers you three different ways to provide data:

• Fixed: You type the value directly into the field.
• Mapped: You connect the output of another component to use its result as the value.
• Javascript: You write Javascript code to dynamically calculate the value.

This flexibility allows you to create more dynamic and connected workflows.

Input Fields

The following fields are available to configure this component. Each field may be visible in different operations:

• Operation: Select the pull request operation to perform.
  • Visible in: Get PR, List PRs, Create PR Comment, Get Review, List Reviews, Create Review
• Comment Body: The text content for the PR comment. Use this for simple comments without review status.
  • Visible in: Create PR Comment
• Limit: Maximum number of items to return (max 1000).
  • Visible in: List PRs, List Reviews
• Mapping Mode: Enable mapping mode to process multiple data records in batch
  • Visible in: Get PR, List PRs, Create PR Comment, Get Review, List Reviews, Create Review
• PR State: Filter pull requests by their state.
  • Visible in: List PRs
• Pull Request Number: The number of the pull request to interact with.
  • Visible in: Get PR, Create PR Comment, Get Review, List Reviews, Create Review
• Repository: Select a repository. The list populates after selecting a credential.
  • Visible in: Get PR, List PRs, Create PR Comment, Get Review, List Reviews, Create Review
• Repository Input Type: Select the input type for the repository.
  • Visible in: Get PR, List PRs, Create PR Comment, Get Review, List Reviews, Create Review
• Repository ID: Pass the repository name in format ‘owner/repo’ (e.g., ‘octocat/Hello-World’). Overrides the dropdown selection.
  • Visible in: Get PR, List PRs, Create PR Comment, Get Review, List Reviews, Create Review
• Review Body: The text content for the formal review. Required for COMMENT and REQUEST_CHANGES events.
  • Visible in: Create Review
• Review Event: Review action: COMMENT (with body), APPROVE (body optional), REQUEST_CHANGES (body required). Note: Cannot APPROVE or REQUEST_CHANGES on your own PR.
  • Visible in: Create Review
• Review ID: The ID of the specific review to retrieve.
  • Visible in: Get Review
• Tool Name: The name of the tool that will be used when this component is connected as a tool. This name will be displayed to the agent when it selects tools to use.
  • Visible in: Get PR, List PRs, Create PR Comment, Get Review, List Reviews, Create Review
• Tool Description: A detailed description of what this tool does. This description will help the agent understand when and how to use this tool effectively.
  • Visible in: Get PR, List PRs, Create PR Comment, Get Review, List Reviews, Create Review
• Tools arguments metadata: Defines the arguments metadata for the tools.
  • Visible in: Get PR, List PRs, Create PR Comment, Get Review, List Reviews, Create Review

Outputs

The component produces results related to the success of the operations performed on GitHub. These outputs allow you to verify if an action was successful or to pass data to subsequent steps in your workflow.

• Data: The primary result of the operation, containing the requested information or status.
• Tool: An interface for using this component as an automated tool in agent-driven workflows.

Output Data Example (JSON)

json { “review_status”: “SUCCESS”, “review_id”: 1234567, “comment_id”: 8901234, “message”: “Review created successfully.”, “errors”: [], “github_response_data”: { “id”: 1234567, “body”: “LGTM”, “state”: “APPROVED” } }

Connectivity

This component is typically used at the end of a code processing or notification workflow.

• Connects To:
  • Reporting/Logging Components: Use the review_status and message outputs to log whether a review was successfully sent.
  • Notification Components: If a Create Review operation is triggered, you might connect the output to an email or Slack notification component to alert the reviewer that their input is required.
  • Conditional Logic: Use the review_status output to determine if the workflow should proceed to the next step (e.g., merging code) or halt due to an error.

Usage Example

Scenario: Automated Code Review Request

1. Trigger: A developer pushes code to a GitHub repository.
2. Action: You use the Create Review operation.
3. Configuration:
   • Select Repository from the dropdown.
   • Enter the Pull Request Number for the new code change.
   • Set Review Event to REQUEST_CHANGES.
   • Enter a Review Body explaining what needs to be fixed (e.g., “Please optimize the database query logic.”).
4. Result: The component sends the review to GitHub. You can monitor the review_status output to ensure it was sent successfully before notifying your team.

Scenario: Fetching PR Details

1. Action: Use the Get PR operation.
2. Configuration:
   • Select Repository.
   • Enter the Pull Request Number.
3. Result: You receive detailed metadata about the PR (title, author, status) in the Data output, which you can then map to other components for further processing.

Important Notes

🔒 GitHub Authentication Needed: To use this component, you must provide a valid GitHub access token with appropriate permissions for pull request operations.

🔴 Component is in Development: GitHubReview is flagged as a development component, meaning its features and stability may change. Users may encounter unexpected behavior or missing functionalities.

🟡 Handle Tokens Securely: Keep your GitHub token confidential. Avoid hard‑coding it in public repositories or exposing it in logs. Use secure credential storage whenever possible.

🟢 Test in a Safe Environment First: Because the component is still in development, try it in a non‑production or sandbox setup to confirm expected behavior before deploying to live projects.

🟡 Component Flag Indicates Unstable State: The is_development = True flag signals that the component may not be fully stable. Avoid relying on it for critical production workflows until a stable release is available.

ℹ️ Inherits Base Inputs/Outputs: GitHubReview uses the same inputs and outputs as its base class, so the available actions and data fields are defined there. Check the base documentation for exact details.

Tips and Best Practices

• Always ensure your GitHub Personal Access Token has the repo scope to avoid permission errors when creating reviews or comments.
• When using Mapping Mode, ensure that the data sources you are mapping from are reliable, as errors in the input data will propagate to the GitHub API calls.
• For Create Review, remember that you cannot approve or request changes on your own Pull Request; the token used must belong to a different user or be a personal access token with sufficient authority.
• If you encounter errors, check the errors output in the component’s result to see if the PR number or repository name is incorrect.

Security Considerations

Ensure that your GitHub Personal Access Token is stored securely within the Nappai credential manager. Never share this token in public repositories or share it with unauthorized team members. The component does not store credentials locally; it relies entirely on the secure credential selection process within Nappai.