Prevent reviewing already reviewed unchanged files

[meness]

Prevent reviewing already reviewed files. Right now, we review all changed files when a new commit is there while the already reviewed files haven't been changed in the commit

[meness]

To prevent reviewing already reviewed files in your Dr. GitHub codebase, you can implement a mechanism to track which files have already been reviewed and check if they have been modified in the new commit before running the review process again.

Here’s a step-by-step approach you can use:

1. Track Reviewed Files

You need a way to store the list of files that have already been reviewed. This can be done in the following ways:
• In the database: If your application uses a database, you can store the files reviewed in each commit or pull request (PR).
• In-memory store: For faster access (and a smaller scale), you could store reviewed files in memory during the lifecycle of the request or pull request.

2. Identify Modified Files in the New Commit

Whenever a new commit is pushed to a pull request, you should identify the files that have been modified in the commit. GitHub provides an API to fetch the files changed in a commit or a PR (via GET /repos/:owner/:repo/pulls/:pull_number/files).

3. Compare Modified Files with Reviewed Files

When new commits are made, compare the list of modified files with the files that have already been reviewed:
• If the file is in the list of previously reviewed files and has not been modified, skip reviewing that file.
• If the file is new or has been modified, proceed with the review process.

4. Workflow Example

Here’s a basic implementation flow:
1. Fetch Changed Files in the Commit/PR: Using GitHub’s API, get the list of files modified in the new commit.
2. Check Against Reviewed Files: Compare the modified files against the list of files previously reviewed.
3. Trigger Review Only for New or Modified Files: If the file has been reviewed before but not modified in the new commit, skip it. Otherwise, initiate the review for the changed file.

5. Code Example

Assuming you have a way to track reviewed files (either in a database or memory), here’s how you can modify your logic:

// Assuming reviewedFiles is an array or Set of previously reviewed file paths
let reviewedFiles: Set = new Set();

// Function to get changed files in a commit or PR
const getChangedFiles = async (commitSha: string): Promise<string[]> => {
// Fetch the changed files from GitHub API or your version control system
// Example for GitHub:
const response = await fetch(https://api.github.com/repos/{owner}/{repo}/commits/${commitSha});
const commitData = await response.json();
return commitData.files.map((file: { filename: string }) => file.filename);
};

// Function to run review only on new or modified files
const reviewChangedFiles = async (commitSha: string) => {
const changedFiles = await getChangedFiles(commitSha);

for (const file of changedFiles) {
if (!reviewedFiles.has(file)) {
// If the file hasn't been reviewed before, run the review logic
await runReview(file);

  // Mark the file as reviewed
  reviewedFiles.add(file);
} else {
  console.log(`Skipping review for already reviewed file: ${file}`);
}

}
};

// Review function (simplified for example)
const runReview = async (file: string) => {
// Trigger your review process here for the file
console.log(Reviewing file: ${file});
};

// Example usage when a new commit is pushed
const handleNewCommit = async (commitSha: string) => {
await reviewChangedFiles(commitSha);
};

6. Optimizations and Considerations

   • Persistence: If you’re using an in-memory store (e.g., reviewedFiles in a Set), the data will be lost if the app restarts. In production, storing this in a persistent database (e.g., linking reviewed files to a commit hash or PR) would be more appropriate.
   • GitHub API Rate Limiting: Be mindful of the GitHub API rate limits when fetching file lists, especially if the repository has a lot of commits or PRs. You can cache the list of modified files and review statuses to avoid excessive API calls.
   • Handling Edge Cases: Consider edge cases like force-pushing, where previously reviewed files may have been rewritten. You might need to invalidate the cache of reviewed files in certain situations (e.g., after a force push or rebase).
   • Efficient Tracking: Instead of comparing against all previously reviewed files, you could optimize by tracking which files were changed only in the current PR and checking those.

7. Integration with the GitHub PR Flow

If you’re using GitHub’s PR and commit events to trigger your review process, the integration might look like this:
1. When a PR is opened/updated: Fetch the list of changed files.
2. Track reviewed files: When a file is reviewed, mark it as reviewed (in your persistent store).
3. On new commits: When a new commit is pushed, only review files that have changed or haven’t been reviewed before.

8. Final Notes

By implementing a system that tracks reviewed files and only processes new or modified files, you can greatly reduce the load on your chatbot review system and avoid redundant processing. This ensures that your bot is only used for the parts of the code that are truly new or have been updated.

[meness]

Solution: store the last reviewed commit hash

[meness]

moved to notion