semantic-release: Problem: ENOCHANGE There are no relevant changes, so no new version is released.
I have problem with constant reporting:
semantic-release ERR! pre Failed to determine new version.
semantic-release ERR! pre ENOCHANGE There are no relevant changes, so no new version is released.
I did manage to get new version and npm publish before, but now i am not able anymore, I did try to report new fix, then even fake feature, etc, but no help.
I did also try on my local machine npm run semantic-release
both before and after git publishing.
Here is the github-project and npm package
About this issue
- Original URL
- State: closed
- Created 8 years ago
- Reactions: 11
- Comments: 25 (3 by maintainers)
IMHO (respectfully)
ENOCHANGE
possibly shouldn’t be a thing. “no change” is a valid and expected state, not an error condition. using ENOCHANGE as a mean of control flow seems like misuse of theError
construct.Grateful for this project, keep up the good work 😃
Some of them may be debatable, but
docs
definitely changes the user experience.If there is no release on npm,
semantic-release
will analyze all the commits in your repo to figure out if a release is necessary. A new release (the initial1.0.0
) will happen only if thecommit-analyzer
determines there is a commit in the history that should trigger a release. By default it’s:perf
,feat
,fix
or a breaking change.If your repo contains only commits that doesn’t trigger a release, then the initial won’t happen. This is the expected behavior as we don’t want to make the initial release until there is actually something to release. For example if your firsts commits are something like
chore: Add license
,ci: Set up Travis
etc we don’t want to release. Once you push a commit likefeat: Initial release
for example the release will happen.In addition, the releases rules are now completely customizeable: see commit-analyzer#release-rules
Here is a config that would trigger a
patch
release for commits that starts withdocs(readme)
:This issue cover a lot of things but I think they should be covered by this new plugin configuration. Some other problems are mentioned but there is corresponding issue already open. Feel free to open a new issue if it’s not the case.
i’m unclear on how the intent is supposed to work. why would “no change” be a non-zero exit code? what’s the convention such that i can merge things into master that arent supposed to cut new releases? i dont want CI failing because it discovered “hey, there’s nothing new.” in fact, yes, i’m aware there’s nothing new, and that’s ok–no reason to exit 1! just askin’ what i’m missing, here
@glebec AFAIK most people read the docs on github, and don’t want to look at some completely unformatted markdown in their node_modules folder.
You can work around this using https://github.com/fullcube/customizable-commit-analyzer
Nope. This is just default Travis CI behavior.
First it runs all tests. A non-zero exit here will fail build. If there was no error with tests, Travis will mark build as passing and run
after success
scripts. Result ofafter success
scripts won’t affect build state.I think
semantic-release
should throwwarn
instead oferror
for such case.@MoeSattler the README.md does change what is shown on npmjs.com. So I guess I have to change it to a
fix
type for now.@thiagofelix no it’s a different case. The problem is that commit analyzer will consider a new version only if there are commits of type
feat
orfix
. I already sent a pull request to fix this: https://github.com/semantic-release/commit-analyzer/pull/13If you’d like more details please check the conversation here: https://github.com/semantic-release/commit-analyzer/issues/12#issuecomment-203166512
Thanks, cheers!