New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
release: false should be the lowest priority rule #377
Comments
PR: #378 |
Another use-case for this change is ignoring nonsense. For example, how would you express this policy as a rule:
? without |
Consider what happens when we expand this test to apply
scope
:so this ruleset says "release fixes as 'patch' for the frontend, but don't release any other fixes in any other scopes"
this test will fail. because of this line: https://github.com/semantic-release/commit-analyzer/blob/master/lib/compare-release-types.js#L11
RELEASE_TYPES
doesn't includefalse
ornull
. so the algorithm starts to analyze our commit using our ruleset, and correctly identifies it as a 'patch'. then it considers the next rule, which saysrelease === false
.false
is not inRELEASE_TYPES
, socompareReleaseTypes()
returnstrue
, and the release value for the commit is incorrectly set tofalse
, instead ofpatch
.this is problematic because it violates the advertised behavior of the release configuration: a commit will always be given the highest possible release value available from the given ruleset. if we consider "no release" the lowest possible release value - as I think is intuitive - then any other release value should take precedence.
the current algorithm treats no release as a special case without priority. or rather, it implicitly treats no release as the highest possible priority of release type, which doesn't make sense. no release cannot be the biggest release.
the current behavior thus renders the use case I've alluded to impossible, so i'll spell that use case out more specifically.
if you have a repo with several scopes, then you might want rules that govern how some scopes get released, and you might want only some of those scopes to get released ever. for example, if you have a project like this:
you might want to say something like this:
"release any frontend or backend commits according to standard rules. fix:patch, feat:minor, break:major. but don't ever release any commits in shared-tools no matter what."
here's an example of what that ruleset might look like:
but for the reasons explained so far, that ruleset will never do what you expect. it will make any release impossible.
the simplest fix and what i would recommend is adding
false
, andnull
to the end of the list ofRELEASE_TYPES
. this would be a breaking change for people who expectrelease: false|null
to override any other possible release value. but that perspective doesn't make any sense, and renders reasonable workflows impossible.The text was updated successfully, but these errors were encountered: