Open pheenomenon opened 4 years ago
What's the status here? I saw that the fix is not working and this bug currently prevents us from using semantic release properly.
The bug/consequence of this is from the underlying micromatch
library used. Either a different library should be used, /
removed from messages passed to micromatch
, or a huge warning be placed in this repository. I would much prefer either of the first 2 options.
To reproduce the behavior: https://runkit.com/60587ebc6a51e10013d391c9/60587ebcc774380013410cab
var micromatch = require("micromatch")
var picomatch = require("picomatch")
console.log("1", micromatch(['abc BUMP_MAJOR def'], ['**BUMP_MAJOR**']));
console.log("2", micromatch(['abc /BUMP_MAJOR def'], ['**BUMP_MAJOR**']));
console.log("3", micromatch(['abc / BUMP_MAJOR def'], ['**BUMP_MAJOR**']));
console.log("4", micromatch(['/abc BUMP_MAJOR def'], ['**BUMP_MAJOR**']));
console.log("5", micromatch(['abc BUMP_MAJOR def/'], ['**BUMP_MAJOR**']));
console.log("6", micromatch(['abc BUMP_MAJOR/def'], ['**BUMP_MAJOR**']));
console.log("7", micromatch(['abc BUMP_MAJOR/ def'], ['**BUMP_MAJOR**']));
console.log("8", micromatch(['/foo/'], ['**f**']));
console.log("1", picomatch('**BUMP_MAJOR**')('abc BUMP_MAJOR def'));
console.log("2", picomatch('**BUMP_MAJOR**')('abc /BUMP_MAJOR def'));
console.log("3", picomatch('**BUMP_MAJOR**')('abc / BUMP_MAJOR def'));
console.log("4", picomatch('**BUMP_MAJOR**')('/abc BUMP_MAJOR def'));
console.log("5", picomatch('**BUMP_MAJOR**')('abc BUMP_MAJOR def/'));
console.log("6", picomatch('**BUMP_MAJOR**')('abc BUMP_MAJOR/def'));
console.log("7", picomatch('**BUMP_MAJOR**')('abc BUMP_MAJOR/ def'));
console.log("8", picomatch('**f**')('/foo/', ));
The bug/consequence of this is from the underlying
micromatch
library used
can you file an issue with micromatch
and reference it here?
@gr2m - I've been trying to figure out if micromatch
is performing as expected or if it is a bug on their end. From reading their documentation and examples, the library feels like purpose meant for path matching. If that's the case, then commit-analyzer
will need to switch to a different matching library.
Would be great to fix this. We often have PRs/commit messages like this:
BREAKING-RELEASE: update to @company/my-cool-library 2.0
Using the problematic /
in npm library names. And very often we forget that the slash in there breaks semantic-release.
[EDIT] Never mind, my commit failed because angular is the preset, and angular both does not recognize !
nor does it recognize BREAKING CHANGES
(with the S
). I was used to conventional commits spec and angular was unexpectedly-to-me tighter
I altered my release config to use conventional commits and all is well. Apologies for the noise
Hi,
Just wanted to chime in to this one, that this problem bites me constantly. We use Bitbucket, and our pull requests follow this pattern Pull request #42: Feature/SMKY-1231 Working with responsiveness
That forward slash is 'poison' for picomatch (which micromatch uses under the covers). Both of those libraries seem to be designed for filesystem glob matching hence it makes sense that it would do some magic when forward slashes are included in strings.
Would be it be possible for commit-analyzer to drop this glob-approach and start to use regular expressions? That would be a big change, I know, but the result would be more predictable.
Or, can someone give a pointer what would be the least effort path to get semantic-release to trigger a patch-release for Bitbucket PRs (looking like the sample line above)?
The below release rules works well, until the commit message has a '/' in it.
For ex BUGFIX-RELEASE: wait to set up event emitter until calling /process
Here are the logs in this case:My release rules looks like this: