materialize/.github/workflows/pr_checklist.yml at main · MaterializeInc/materialize · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
# Copyright Materialize, Inc. and contributors. All rights reserved.
#
# Use of this software is governed by the Business Source License
# included in the LICENSE file at the root of this repository.
#
# As of the Change Date specified in that file, in accordance with
# the Business Source License, use of this software will be governed
# by the Apache License, Version 2.0.
name: PR Checklist

on:
  # pull_request_target runs with the base branch's GITHUB_TOKEN (write
  # access), even for fork PRs. This is safe ONLY because the workflow posts a
  # static comment and never checks out or executes PR code. Do NOT add steps
  # that checkout, build, or run code from the PR — that would let a malicious
  # fork PR execute arbitrary code with write permissions to this repo.
  pull_request_target: # zizmor: ignore[dangerous-triggers]
    types: [opened]

permissions:
  pull-requests: write

jobs:
  checklist:
    runs-on: ubuntu-latest
    steps:
      - name: Post checklist comment
        uses: actions/github-script@v7
        with:
          script: |
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.payload.pull_request.number,
              body: `Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

            ### PR title guidelines

            - Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
            - Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
            - Prefix with area if helpful: \`compute: \`, \`storage: \`, \`adapter: \`, \`sql: \`

            ### Pre-merge checklist

            - [ ] The PR title is descriptive and will make sense in the git log.
            - [ ] This PR has adequate test coverage / QA involvement has been duly considered. ([trigger-ci for additional test/nightly runs](https://trigger-ci.dev.materialize.com/pr/${context.payload.pull_request.number}))
            - [ ] If this PR includes major [user-facing behavior changes](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/guide-changes.md#what-changes-require-a-release-note), I have pinged the relevant PM to schedule a changelog post.
            - [ ] This PR has an associated up-to-date [design doc](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/design/README.md), is a design doc ([template](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/design/00000000_template.md)), or is sufficiently small to not require a design.
              <!-- Reference the design in the description. -->
            - [ ] If this PR evolves [an existing \`$T ⇔ Proto$T\` mapping](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/command-and-response-binary-encoding.md) (possibly in a backwards-incompatible way), then it is tagged with a \`T-proto\` label.
            - [ ] If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label ([example](https://github.com/MaterializeInc/cloud/pull/5021)).
              <!-- Ask in #team-cloud on Slack if you need help preparing the cloud PR. -->
            `
            });