Ignore default rules

[landau]

Good day -

I'm looking for support. The documentation states:

If you define custom release rules the default rules will be used if nothing matched.

Is it possible to disable/override that behavior? My goal is to set this plugin t to match for specific scope. In other words, the commit analyzer should only match commits that look something like fix(service/deps): Use express@4.3.2. The plugin should not match a commit that looks like fix(deps): Use express@4.3.2 or anything without a scope of service*. I'm using specific scopes because my particular use case is within a monorepo and certain packages should not be published if the commit is unrelated.

"plugins": [
    [
      "@semantic-release/commit-analyzer",
      {
        "preset": "angular",
        "releaseRules": [
          { "breaking": true, "scope": "/service.*/", "release": "major" },
          { "revert": true, "scope": "/service.*/", "release": "patch" },
          { "type": "feat", "scope": "/service.*/", "release": "minor" },
          { "type": "fix", "scope": "/service.*/", "release": "patch" },
          { "type": "perf", "scope": "/service.*/", "release": "patch" }
        ]
      }
    ]
]

Thanks for your time.

[landau]

Looking through the code base, it seems like an additional option would be simple to integrate to ignore default rules https://github.com/semantic-release/commit-analyzer/blob/master/index.js#L47

[Zashy]

I came here looking for something similar. This would fulfil my use case too.

I just wanted perf to not publish a release. So either this, or allowing another release type of like none which does not trigger a release.

[semantic-release-bot]

🎉 This issue has been resolved in version 6.2.0 🎉

The release is available on:

• npm package (@next dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[semantic-release-bot]

🎉 This issue has been resolved in version 7.0.0-beta.4 🎉

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[elliotdickison]

@pvdlg I'm having trouble understanding how the release: false feature solves this problem. I am trying to only release for the scope "app" and ignore all other scopes. The following release rules result in nothing being released:

[
  { scope: "app", breaking: true, release: "major" },
  { scope: "app", type: "feat", release: "minor" },
  { scope: "app", release: "patch" },
  { scope: "*", release: false },
]

Any ideas? Thanks!

[caribou-code]

@pvdlg I'm looking for exactly the same answer. Did you find a solution?

Only thing I can think of is to disable releases for each specific scope you want to ignore e.g.

[
  { scope: "app", breaking: true, release: "major" },
  { scope: "app", type: "feat", release: "minor" },
  { scope: "app", release: "patch" },
  { scope: 'scopeToIgnore1', release: false },
  { scope: 'scopeToIgnore2', release: false },
]

Obviously not ideal, and not manageable if there's a lot of scopes or the list keeps growing. It would be preferable if the pattern you provided worked. Or at least some way of doing a negative match like { scope: '!app', release: false }

[elliotdickison]

@caribou-code we ended up applying this patch with yarn and it's been working great for us:

diff --git a/lib/default-release-rules.js b/lib/default-release-rules.js
index 338e4ef1838acea860aac4a2c59b3c89f2ea8193..339954ee67eb024555c83c0d1f2152a5acf55c84 100644
--- a/lib/default-release-rules.js
+++ b/lib/default-release-rules.js
@@ -3,32 +3,8 @@
  *
  * @type {Array}
  */
-module.exports = [
-  {breaking: true, release: 'major'},
-  {revert: true, release: 'patch'},
-  // Angular
-  {type: 'feat', release: 'minor'},
-  {type: 'fix', release: 'patch'},
-  {type: 'perf', release: 'patch'},
-  // Atom
-  {emoji: ':racehorse:', release: 'patch'},
-  {emoji: ':bug:', release: 'patch'},
-  {emoji: ':penguin:', release: 'patch'},
-  {emoji: ':apple:', release: 'patch'},
-  {emoji: ':checkered_flag:', release: 'patch'},
-  // Ember
-  {tag: 'BUGFIX', release: 'patch'},
-  {tag: 'FEATURE', release: 'minor'},
-  {tag: 'SECURITY', release: 'patch'},
-  // ESLint
-  {tag: 'Breaking', release: 'major'},
-  {tag: 'Fix', release: 'patch'},
-  {tag: 'Update', release: 'minor'},
-  {tag: 'New', release: 'minor'},
-  // Express
-  {component: 'perf', release: 'patch'},
-  {component: 'deps', release: 'patch'},
-  // JSHint
-  {type: 'FEAT', release: 'minor'},
-  {type: 'FIX', release: 'patch'},
-];
+// PATCH: @semantic-release/commit-analyzer will fall back to these default
+// rules if no custom rules are matched. If you only want to apply custom rules
+// and fall back to no release if no custom rules are matched then you're out of
+// luck. Hence this patch, which clears out all the default rules.
+module.exports = [];

[caribou-code]

@elliotdickison I think I'm right in saying your patch solution discards all default rules, but those are super useful to avoid hardcoding that config in multiple places

[elliotdickison]

Correct, if the default rules are useful to you then that patch won’t be helpful. We did not want the default rules and the patch allowed us to apply our own custom rules without interference.

[jedwards1211]

@pvdlg release: false wins over all other release types...was that intentional?

If the priority were 'major' > 'minor' > 'patch' > false then we could opt out of the default rules by putting a { release: false } rule last.

In my case I only intended to release a monorepo subpackage when its name is in the scope, so I was able to avoid releasing otherwise by using { scope: undefined, release: false }.