Merge pull request #188 from BodrickLight/feature/scopes

feat: change minor pattern to support optional conventional commit scopes

action.yml

@@ -31,7 +31,7 @@ inputs:
   minor_pattern:
     description: "A string which, if present in a git commit, indicates that a change represents a minor (feature) change. Wrap with '/' to match using a regular expression."
     required: true
-    default: "/feat:/"
+    default: "/feat(\\(.+\\))?:/"
   minor_regexp_flags:
     description: "A string which indicates the flags used by the `minor_pattern` regular expression. Supported flags: idgs"
     required: false

guide.md

@@ -100,7 +100,7 @@ If your project contains multiple services which you wish to version independent
 | Value | Description |
 | --- | --- |
 | `tag_prefix` | The prefix to use for the tag. Defaults to `v`, generally you will use either `v` or an empty string. Note that the tag format is distinct from the version. Tags used for versioning must always follow the pattern `{tag_prefix}{major}.{minor}.{patch}` with and optional `-{namespace}` suffix. |
-| `major_pattern` and `minor_pattern` | These strings are used to determine the type of version to create. If any commit message since matches the `major_pattern` the major version will be incremented, if it matches the `minor_pattern` the minor version will be incremented. If neither pattern matches, the patch version will be incremented. These can be specified either as strings or as regular expression by wrapping the expression in `/`. The defaults follow [Conventional Commits](https://www.conventionalcommits.org/): `/!:|BREAKING CHANGE:/` for major and `/feat:/` for minor. |
+| `major_pattern` and `minor_pattern` | These strings are used to determine the type of version to create. If any commit message since matches the `major_pattern` the major version will be incremented, if it matches the `minor_pattern` the minor version will be incremented. If neither pattern matches, the patch version will be incremented. These can be specified either as strings or as regular expression by wrapping the expression in `/`. The defaults follow [Conventional Commits](https://www.conventionalcommits.org/): `/!:|BREAKING CHANGE:/` for major and `/feat(\(.+\))?:/` for minor. |
 | `version_format` | A value such as `${major}.${minor}.${patch}-prerelease${increment}` that will be used to format the version value of the output, **formatting this value is the only effect of this input parameter!** It is not used for parsing or any other purpose. It is a convenient alternative to formatting the output in a subsequent step. |
 | `user_format_type` | Indicates the format of the `authors` output. Can be `json` or `yaml`. |
 | `enable_prerelease_mode` | If true, major changes to versions starting with 0 will result in a minor change, preventing ths initial version `1.0.0`` from being created automatically by someone checking in a commit with the major pattern. |

readme.md

@@ -14,8 +14,8 @@ release. To accomplish this, the next version number is calculated along with
 a commit increment indicating the number of commits for this version. The
 commit messages are inspected to determine the type of version change the next
 version represents. By default, this action follows [Conventional Commits](https://www.conventionalcommits.org/)
-patterns: commits with `feat:` trigger minor version bumps, and commits with a `!` suffix
-(e.g., `feat!:`, `fix!:`) or containing `BREAKING CHANGE:` trigger major version bumps.
+patterns: commits with `feat:` or `feat(scope):` trigger minor version bumps, and commits with a `!` suffix
+(e.g., `feat!:`, `fix!:`, `refactor(scope)!:`) or containing `BREAKING CHANGE:` trigger major version bumps.
 
 # Background
 
@@ -51,7 +51,7 @@ _Unless the current commit is already tagged, the version produced by this actio
 ## Major and Minor Versions
 
 The commit messages for the span of commits from the last tag are checked for the
-presence of version bump patterns. By default, `feat:` triggers a minor version bump,
+presence of version bump patterns. By default, `feat:` or `feat(scope):` trigger a minor version bump,
 while `!:` (e.g., `feat!:`, `fix!:`) or `BREAKING CHANGE:` triggers a major version bump. If a pattern
 is encountered that commit is treated as the start of a major or minor version
 instead of the default patch level. As with normal commits the implied version
@@ -85,7 +85,7 @@ it will be given the new version if the build were to be retriggered, for exampl
     # A string which indicates the flags used by the `major_pattern` regular expression. Supported flags: idgs
     major_regexp_flags: ""
     # Same as above except indicating a minor change, supports regular expressions wrapped with '/'
-    minor_pattern: "/feat:/"
+    minor_pattern: "/feat(\\(.+\\))?:/"
     # A string which indicates the flags used by the `minor_pattern` regular expression. Supported flags: idgs
     minor_regexp_flags: ""
     # A string to determine the format of the version output

src/ActionConfig.ts

@@ -13,7 +13,7 @@ export class ActionConfig {
   /** A string which indicates the flags used by the `majorPattern` regular expression. */
   public majorFlags: string = "";
   /** A string which, if present in a git commit, indicates that a change represents a minor (feature) change. Wrap with '/' to match using a regular expression. */
-  public minorPattern: string = "/feat:/";
+  public minorPattern: string = "/feat(\\(.+\\))?:/";
   /** A string which indicates the flags used by the `minorPattern` regular expression. */
   public minorFlags: string = "";
   /** Pattern to use when formatting output version */

src/cli.ts

@@ -33,7 +33,7 @@ program
   .option(
     "-m, --minor-pattern <pattern>",
     "Regex pattern for minor version bumps",
-    "/feat:/",
+    "/feat(\\(.+\\))?:/",
   )
   .option("--minor-flags <flags>", "Flags for minor pattern regex", "")
   .option(

src/main.test.ts

@@ -217,6 +217,20 @@ testInterfaces.forEach((testInterface) => {
       timeout,
     );
 
+    test(
+      "Minor commits with conventional commit scopes bump minor version",
+      async () => {
+        const repo = createTestRepo(testRunner); // 0.0.0+0
+
+        repo.makeCommit("Initial Commit"); // 0.0.1+0
+        repo.makeCommit("feat(scope): Second Commit"); // 0.1.0+0
+        const result = await repo.runAction();
+
+        expect(result.formattedVersion).toBe("0.1.0+0");
+      },
+      timeout,
+    );
+
     test(
       "Tags start new version",
       async () => {