|
| 1 | +############################################################################### |
| 2 | +# This file configures "Semantic Pull Requests", which is documented here: |
| 3 | +# https://github.com/zeke/semantic-pull-requests |
| 4 | +# |
| 5 | +# This action/spec implements the "Conventional Commits" RFC which is |
| 6 | +# available here: |
| 7 | +# https://www.notion.so/coderhq/Conventional-commits-1d51287f58b64026bb29393f277734ed |
| 8 | +############################################################################### |
| 9 | + |
| 10 | +# Scopes are optionally supplied after a 'type'. For example, in |
| 11 | +# |
| 12 | +# feat(cdr): autostart ui |
| 13 | +# |
| 14 | +# '(cdr)' is the scope. Scopes are used to signify where the change occurred. |
| 15 | +scopes: |
| 16 | + # The Coder product (front/back/deploy) (path: product/coder) |
| 17 | + - cdr |
| 18 | + |
| 19 | + # The Coder CLI (path: product/coder/service/cli) |
| 20 | + - cli |
| 21 | + |
| 22 | + # The Coder product e2e suite (path: product/coder/e2e) |
| 23 | + - e2e |
| 24 | + |
| 25 | + # A change to a shared library module (path: lib/) |
| 26 | + - lib |
| 27 | + |
| 28 | +# We only check that the PR title is semantic. The PR title is automatically |
| 29 | +# applied to the "Squash & Merge" flow as the suggested commit message, so this |
| 30 | +# should suffice unless someone drastically alters the message in that flow. |
| 31 | +titleOnly: true |
| 32 | + |
| 33 | +# Types are the 'tag' types in a commit or PR title. For example, in |
| 34 | +# |
| 35 | +# chore: fix thing |
| 36 | +# |
| 37 | +# 'chore' is the type. |
| 38 | +types: |
| 39 | + # A build of any kind. |
| 40 | + - build |
| 41 | + |
| 42 | + # A RELEASED fix that will NOT be back-ported. The originating issue may have |
| 43 | + # been discovered internally or externally to Coder. |
| 44 | + - fix |
| 45 | + |
| 46 | + # Any code task that is ignored for changelog purposes. Examples include |
| 47 | + # devbin scripts and internal-only configurations. |
| 48 | + - chore |
| 49 | + |
| 50 | + # Any work performed on CI. |
| 51 | + - ci |
| 52 | + |
| 53 | + # An UNRELEASED correction. For example, features are often built |
| 54 | + # incrementally and sometimes introduce minor flaws during a release cycle. |
| 55 | + # Corrections address those increments and flaws. |
| 56 | + - correct |
| 57 | + |
| 58 | + # Work that directly implements or supports the implementation of a feature. |
| 59 | + - feat |
| 60 | + |
| 61 | + # A fix for a RELEASED bug (regression fix) that is intended for patch-release |
| 62 | + # purposes. |
| 63 | + - hotfix |
| 64 | + |
| 65 | + # A refactor changes code structure without any behavioral change. |
| 66 | + - refactor |
| 67 | + |
| 68 | + # A git revert for any style of commit. |
| 69 | + - revert |
| 70 | + |
| 71 | + # Adding tests of any kind. Should be separate from feature or fix |
| 72 | + # implementations. For example, if a commit adds a fix + test, it's a fix |
| 73 | + # commit. If a commit is simply bumping coverage, it's a test commit. |
| 74 | + - test |
0 commit comments