diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 3beda36c8..61ea4df10 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,31 +1,32 @@ # Changes - + # Submitter Checklist -- [ ] ๐Ÿ“ Please ensure your commit message is clear and informative. For guidance on crafting effective commit messages, refer to the How to write a git commit message guide. We prefer the commit message to be included in the PR body itself rather than a link to an external website (ie: Jira ticket). +- [ ] ๐Ÿ“ Ensure your commit message is clear and informative. Refer to the How to write a git commit message guide. Include the commit message in the PR body rather than linking to an external site (e.g., Jira ticket). -- [ ] โ™ฝ Before submitting a PR, run make test lint to avoid unnecessary CI processing. For an even more efficient workflow, consider installing [pre-commit](https://pre-commit.com/) and running pre-commit install in the root of this repository. +- [ ] โ™ฝ Run make test lint before submitting a PR to avoid unnecessary CI processing. Consider installing [pre-commit](https://pre-commit.com/) and running pre-commit install in the repository root for an efficient workflow. -- [ ] โœจ We use linters to maintain clean and consistent code. Please ensure you've run make lint before submitting a PR. Some linters offer a --fix mode, which can be executed with the command make fix-linters (ensure [markdownlint](https://github.com/DavidAnson/markdownlint) and [golangci-lint](https://github.com/golangci/golangci-lint) tools are installed first). +- [ ] โœจ We use linters to maintain clean and consistent code. Run make lint before submitting a PR. Some linters offer a --fix mode, executable with make fix-linters (ensure [markdownlint](https://github.com/DavidAnson/markdownlint) and [golangci-lint](https://github.com/golangci/golangci-lint) are installed). -- [ ] ๐Ÿ“– If you're introducing a user-facing feature or changing existing behavior, please ensure it's properly documented. +- [ ] ๐Ÿ“– Document any user-facing features or changes in behavior. -- [ ] ๐Ÿงช While 100% coverage isn't a requirement, we encourage unit tests for any code changes where possible. +- [ ] ๐Ÿงช While 100% coverage isn't required, we encourage unit tests for code changes where possible. -- [ ] ๐ŸŽ If feasible, please check if an end-to-end test can be added. See [README](https://github.com/openshift-pipelines/pipelines-as-code/blob/main/test/README.md) for more details. +- [ ] ๐ŸŽ If feasible, add an end-to-end test. See [README](https://github.com/openshift-pipelines/pipelines-as-code/blob/main/test/README.md) for details. -- [ ] ๐Ÿ”Ž If there's any flakiness in the CI tests, don't necessarily ignore it. It's better to address the issue before merging, or provide a valid reason to bypass it if fixing isn't possible (e.g., token rate limitations). +- [ ] ๐Ÿ”Ž Address any CI test flakiness before merging, or provide a valid reason to bypass it (e.g., token rate limitations). -- If you are adding a provider feature, please fill up the following details which provider this feature supports: +- If adding a provider feature, fill in the following details: - - [ ] GitHub - - [ ] GitHub Webhook - - [ ] Gitea - - [ ] Gitlab - - [ ] Bitbucket Cloud - - [ ] Bitbucket Server/DC +| Git Provider | Supported | +|------------------|-----------| +| GitHub App | โœ…๏ธ | +| GitHub Webhook | โŒ๏ธ | +| Gitea | โŒ๏ธ | +| GitLab | โŒ๏ธ | +| Bitbucket Cloud | โŒ๏ธ | +| Bitbucket Server | โŒ๏ธ | - (make sure to update the documentation accordingly) + (update the documentation accordingly)