Now that we have everything set up with semantic-release and we have a feature commit, let's push that up and watch TravisCI use semantic-release do our library release automatically.
Note, an alternative (and arguably better) solution is to create a
test:watch and then remove the
-w from the
I have a node module that was at version 1.0.1. It was already configured and running on travis-ci. In this case, do I still have to change my package.json version tag to "0.0.0-semantically-released"? I'm asking because after setting up semantic-release following your tips and committing with commitizen, on travis-ci a get the error when semantic-release pre is run:
"Failed to determine new version"
I also tried to make other changes, commit them, and before pushing them to Github, ran semantic-release pre on my notebook, getting the same error. What could be the problem?
Hmmm.... Not sure what that could be. I would recommend you file an issue in the semantic-release repo with a link to your library. Good luck!
Hi Kent, Great series! I have followed along without a problem until this video. I have navigated to the Travis URL in my account like you do at 1:04 in the video, but I do not see anything to say that my project is building or any CI running. I did see an issue reported with building on Mac's, could this be it? Thanks.
I needed to have the travis.yaml file pre-pushed to the project before this would trigger. So I guess before I could automate the push, I had to do one last manual push :)
Great! Glad you worked that out. Let me know if you have further questions :-)
Thank you, Kent, I'm afraid I do. My Travis build are timing out, the only errors I see are 'unable to download an optional dependency', but I read this should not be an issue. The only difference I have to your setup at the moment maybe is I don't have an SSH key setup to Github. So when I push, I manually enter my user and pw, I guess this could be fully pushing to Github before Travis has a chance? I have read about adding travis_wait to the :install life cycle of Travis, but you have to prefix this to failing command and I can't seem to find what that is :/
Just in case you fancy a look at the report :) https://github.com/philipjc/starwars-names/issues/2
You shouldn't need an SSH key, but you definitely need a
GH_TOKEN environment variable which should have been set up for you by
semantic-release-cli setup. Do you have that?
I checked Github and it shows semantic-release create a access token, yes
Could you link me to your repo?
Found your problem... this line should say
before_script :-) cheers!
Whhuuuut your kidding! Ha. Thank you so much for noticing that (it's getting late here :)) Apologies for using your time on something I should have noticed. Thank's again!
Update It worked!
Off topic question, Kent Dodds. What is the landing page you use for chrome that has the font suggestions?
I'd like to download this, whether on chrome or firefox, to get more familiar with good typography fonts. Thanks!
Good question! Do you mind asking on my AMA? http://faq.kentcdodds.com
Any recommendations for taking this further to update/commit the changelog.md from the semantic-release/commitizen git data?
Is it true, that with semantic release your installed module doesn't know which version it is? I mean, normally I would implement command
myModule -v, which reads version from
package.json file. But with semantic release version in
package.json doesn't change.
semantic-release pre script updates your
version field, so getting a version works fine (though during development it doesn't show the current version which is fine with me).
Unfortunately, I didn't manage to make my module output correct version, as
version property remains
package.json. Fortunately, I no longer need such option, because standard command
npm view myModule version outputs version correctly.
Yes, this will happen when you're developing locally, but when it's actually been released and you install it from npm, it will have the proper version number. I'm doing this with my module
p-s. You can see where I get the version here. If you look in the source
package.json, you'll see
0.0.0-semantically-released, but if you look at the distributed
package.json you'll see
Hi Kent! Nice work!
Where can I find the rules which decides what messages appears on the github
release. For example, for
chore type commits, the messages do not appear. But for
feat they do appear. Should I be worried with this? Is there anyway to configure which type of messages should appear on the
release. change log of github?
Good quesiton! That functionality is handled by this package: https://github.com/semantic-release/commit-analyzer
I have already looked at that before and it's source code only does what it says: "get version type from commits". I am still intrigued. Any other idea?
It could also be this one
https://github.com/semantic-release/release-notes-generator. But its source code does not have much!
Sorry, I misunderstood your initial question. You're correct. There are a lot of small modules in use, but that's the repo that does it. It uses this: https://github.com/conventional-changelog/conventional-changelog/tree/master/packages/conventional-changelog which uses other modules. You could follow things around a bit :)