[BUG]: Code rabbit is a bit too eager in announcing itself

[BenHenning]

Describe the bug

Since #6268 was merged, coderabbit is now enabled for opt-in reviews. However, coderabbit is a bit over-eager and announces itself for every PR. This adds a lot of email overhead for PRs, and seems largely unnecessary (and a bit spammy).

Steps To Reproduce

Create any PR and observe that coderabbit automatically posts a comment that it's disabled but can be used with the coderabbit review command.

Expected Behavior

It would be preferred if coderabbit didn't announce itself at all. This should be configurable using coderabbit settings.

Screenshots/Videos

No response

What device/emulator are you using?

No response

Which Android version is your device/emulator running?

No response

Which version of the Oppia Android app are you using?

No response

Additional Context

No response

[adanaamir]

Hi! I went through the issue description and have a clear understanding of the problem. I'd like to work on implementing the required configuration change. Could you please assign this issue to me? Thank you!

[BenHenning]

Hi @adanaamir. Sure, but can you first explain briefly what changes you think will be necessary to address this issue & how you'll verify that those changes are correct?

[adanaamir]

From the issue description, my understanding is that CodeRabbit is currently configured to automatically post an informational comment on every new PR, even though reviews are opt-in. I plan to identify where CodeRabbit's configuration was introduced (likely in the changes from #6268 or its configuration file, .coderabbit.yaml) and update it so that these automatic announcement comments are disabled while keeping opt-in reviews available. (likely reviews.review_status, need to confirm exact key against current CodeRabbit docs)

To verify:

• Update the config
• Open a test PR and confirm CodeRabbit stays silent
• Manually trigger @ coderabbitai review on that PR to confirm opt-in review still works
• Make sure no other useful CodeRabbit comment gets accidentally suppressed in the process

[BenHenning]

Thanks @adanaamir. Assigning this over to you. Some things to note:

• Coderabbit seems to be configured to post its default message by default.
• I believe .coderabbit.yaml is indeed the file to configure.
• This may be as simple as just setting reviews.review_status to false but this needs to be backed up with Coderabbit's documentation so that we understand it doesn't affect requested reviews. We only want the automatic message that posts when a review isn't requested to be silenced.
• Your verification process probably won't work because we can't test something before it gets released. However, verifying this is probably tricky to do in a fork repository. If there isn't a way to test it in your fork (i.e. before we merge the fix), then we can probably assume it will work correctly based purely on documentation (not ideal, but not uncommon for a repository configuration thing like this).

[adanaamir]

Hi! @BenHenning I investigated this further and reviewed the CodeRabbit documentation before making the change.

From the documentation, reviews.review_status is described as controlling whether review status messages (such as skipped-review messages) are posted. Based on that, I updated .coderabbit.yaml to set:

reviews:
  review_status: false

The documentation also states that manually requested reviews can still be triggered using @ coderabbitai review, although I couldn't find documentation explicitly stating that review_status itself has no effect on manually requested reviews. My understanding is that review_status controls only the status messaging, while the manual review workflow is documented separately.

Regarding verification, I looked into whether this could be tested before merging. From what I could determine, I wasn't able to find a reliable way to verify this behavior in a fork repository, so I understand why you mentioned that verification may need to rely on the documentation in this case.

Does this approach look reasonable? If so, should I go ahead and open a PR with this change?