Update the comment for review checklist with an item for CI workflows (…

…#10471) (#10473)

Signed-off-by: Florent Poinsard <florent.poinsard@outlook.fr>
Signed-off-by: Rohit Nayak <rohit@planetscale.com>

.github/workflows/comment_pull_request.yml

@@ -0,0 +1,49 @@
+name: comment_pull_request
+on:
+  pull_request_target:
+    types: [opened, reopened, ready_for_review]
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  review_checklist:
+    if: ${{ !github.event.pull_request.draft }}
+    runs-on: ubuntu-latest
+    name: Comment Pull Request with the Review Checklist
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+
+      - name: Comment PR
+        uses: thollander/actions-comment-pull-request@v1
+        with:
+          comment_includes: 'Review Checklist'
+          message: |
+            ### Review Checklist
+            
+            Hello reviewers! :wave: Please follow this checklist when reviewing this Pull Request.
+            
+            #### General
+            - [ ] Ensure that the Pull Request has the correct `release notes` label. `release notes none` should only be used for PRs that are so trivial that they need not be included.
+            - [ ] If a new flag is being introduced, review whether it is really needed. The flag names should be clear and intuitive (as far as possible), and the flag's help should be descriptive.
+            - [ ] If a workflow is added or modified, each items in `Jobs` should be named in order to mark it as `required`. If the workflow should be required, the GitHub Admin should be notified.
+  
+            #### Bug fixes
+            - [ ] There should be at least one unit or end-to-end test.
+            - [ ] The Pull Request description should either include a link to an issue that describes the bug OR an actual description of the bug and how to reproduce, along with a description of the fix.
+
+            #### Non-trivial changes
+            - [ ] There should be some code comments as to why things are implemented the way they are.
+
+            #### New/Existing features
+            - [ ] Should be documented, either by modifying the existing documentation or creating new documentation.
+            - [ ] New features should have a link to a feature request issue or an RFC that documents the use cases, corner cases and test cases.
+
+            #### Backward compatibility            
+            - [ ] Protobuf changes should be wire-compatible.
+            - [ ] Changes to `_vt` tables and RPCs need to be backward compatible.
+            - [ ] `vtctl` command output order should be stable and `awk`-able.
+
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}