diff --git a/.github/workflows/init_pr.yaml b/.github/workflows/init_pr.yaml new file mode 100644 index 00000000000..170cdc72bf1 --- /dev/null +++ b/.github/workflows/init_pr.yaml @@ -0,0 +1,63 @@ +name: Initialize Pull Request +on: + pull_request: + types: opened + +permissions: read-all + +jobs: + init_pr: + runs-on: ubuntu-latest + permissions: + pull-requests: write + steps: + - name: Check out + uses: actions/checkout@v3 + + - uses: actions-ecosystem/action-add-labels@v1 + with: + labels: | + NeedsWebsiteDocsUpdate + NeedsDescriptionUpdate + + - uses: wow-actions/auto-comment@v1 + name: Comment Review Checklist + with: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + pullRequestOpened: | + ### Review Checklist + + Hello reviewers! :wave: Please follow this checklist when reviewing this Pull Request. + + #### General + - [ ] Ensure that the Pull Request has a descriptive title. + - [ ] If this is a change that users need to know about, please apply the \`release notes (needs details)\` label so that merging is blocked unless the summary release notes document is included. + - [ ] If a test is added or modified, there should be a documentation on top of the test to explain what the expected behavior is what the test does. + + #### If a new flag is being introduced: + - [ ] Is it really necessary to add this flag? + - [ ] Flag names should be clear and intuitive (as far as possible) + - [ ] Help text should be descriptive. + - [ ] Flag names should use dashes (\`-\`) as word separators rather than underscores (\`_\`). + + #### If a workflow is added or modified: + - [ ] Each item in \`Jobs\` should be named in order to mark it as \`required\`. + - [ ] If the workflow should be required, the maintainer team should be notified. + + #### Bug fixes + - [ ] There should be at least one unit or end-to-end test. + - [ ] The Pull Request description should include a link to an issue that describes the bug. + + #### 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. + - [ ] RPC changes should be compatible with vitess-operator + - [ ] If a flag is removed, then it should also be removed from VTop, if used there. \ No newline at end of file