Automatically Releasing with TravisCI

Kent C. Dodds
InstructorKent C. Dodds
Share this video with your friends

Social Share Links

Send Tweet
Published 9 years ago
Updated 6 years ago

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.

[00:00] It's the moment you've all been waiting for. We are going to push our code to github. Because semantic release set up a Travis build for us, we're going to look at what that Travis build looks like. We'll see that semantic release releases a new version of our library for us automatically based off of our commit messages.

[00:18] Just in review, we'll look at the git log to see we have two commits that haven't been pushed to master. They're both following the convention that we need to. That semantic release knows what version to push out to NPM.

[00:32] If we just look at our get status, we don't have any remaining commits locally, but we are ahead by origin master with two commits. Let's go ahead and push these to master.

[00:45] While that's running, we see that one of those commits caused this issue. We can see the other commit caused the simplified releases issue. Now, we can go at our Travis build, which we didn't have to set up. Semantic release did that for us.

[01:04] I'll go to travisci.org. We'll go to our repo, Star Wars, names. We'll see that this has been set up for us. It's already running. It's running our NPM install right now. This is our first build. We'll go ahead and let this run. We'll follow the log as we go.

[01:23] Let's run our test. It looks like we have a problem. If we look back at our package JSON, our test that adds this -w here. Let's go ahead and add another script called "test single," which removes the -w, it only runs once. Then in our Travis, instead of running test, we'll run test single. Let's go ahead and commit that following our commit strategy.

[01:53] Before we do this, let's cancel this build, because we're going to build another one. We'll get status, we'll get add everything, and then, we'll run NPM run commit. Let's expand this out a little bit.

[02:11] This is a chore related to the build at our subject. We'll add a longer description. We don't have any issues related to this. Now, we'll push this. That gets pushed up. Travis will automatically run this build for us.

[02:25] If we want to jump ahead, we'll look at our build history and jump right to that build. It will take a moment before it actually starts. It's started. Now, it's followed the log.

[02:37] Our dependencies have been installed. Now, it's running our test. It exited with zero. Now, it's running semantic release, which will publish our new version to NPM. It looks like it has been published as 1.5.0which makes sense, because before, it was 1.4.

[02:54] Now, let's go see all the things that semantic release did for us automatically. If we go back to our github repository, we'll go to releases. We have this 1.5 release. It has our feature based off of our commit. It references the issue that it caused. It has a link to the actual commit.

[03:15] Now, if we go to our package on NPM, we'll see that 1.5.0is the latest of nine releases. It was published a minute ago. All of this was done magically for us by semantic release. Our build process, we didn't have to decide is this a minor or a major.

[03:37] We didn't have to worry about creating our changelog in our releases. All of this just happened magically for us because of semantic release and is following a couple conventions in our git commit messages using Commitizen.

Kent C. Dodds
Kent C. Doddsinstructor
~ 9 years ago

Note, an alternative (and arguably better) solution is to create a test:watch and then remove the -w from the test command.

Rodrigo Medeiros
Rodrigo Medeiros
~ 9 years ago

Hi Kent,

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?

Kent C. Dodds
Kent C. Doddsinstructor
~ 9 years ago

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!

Philip Cox
Philip Cox
~ 9 years ago

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.

Phil

Philip Cox
Philip Cox
~ 9 years ago

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 :)

Kent C. Dodds
Kent C. Doddsinstructor
~ 9 years ago

Great! Glad you worked that out. Let me know if you have further questions :-)

Philip Cox
Philip Cox
~ 9 years ago

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

Kent C. Dodds
Kent C. Doddsinstructor
~ 9 years ago

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?

Philip Cox
Philip Cox
~ 9 years ago

I checked Github and it shows semantic-release create a access token, yes

Kent C. Dodds
Kent C. Doddsinstructor
~ 9 years ago

Could you link me to your repo?

Philip Cox
Philip Cox
~ 9 years ago

Sure, https://github.com/philipjc/starwars-names

Kent C. Dodds
Kent C. Doddsinstructor
~ 9 years ago

Found your problem... this line should say script, not before_script :-) cheers!

Philip Cox
Philip Cox
~ 9 years ago

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!

Jonathan
Jonathan
~ 9 years ago

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!

Kent C. Dodds
Kent C. Doddsinstructor
~ 9 years ago

Good question! Do you mind asking on my AMA? http://faq.kentcdodds.com

Steve Schwarz
Steve Schwarz
~ 9 years ago

Any recommendations for taking this further to update/commit the changelog.md from the semantic-release/commitizen git data?

Kent C. Dodds
Kent C. Doddsinstructor
~ 9 years ago

Part of the beauty of using semantic-release is not having to manage a changelog at all. See what the angular-formly changelog looks like :-)

If you still want to have a changelog, I recommend you take a look at clog-cli

Sergey
Sergey
~ 8 years ago

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.

Kent C. Dodds
Kent C. Doddsinstructor
~ 8 years ago

No, the semantic-release pre script updates your package.json version field, so getting a version works fine (though during development it doesn't show the current version which is fine with me).

Sergey
Sergey
~ 8 years ago

Unfortunately, I didn't manage to make my module output correct version, as version property remains 0.0.0-semantically-released in package.json. Fortunately, I no longer need such option, because standard command npm view myModule version outputs version correctly.

Kent C. Dodds
Kent C. Doddsinstructor
~ 8 years ago

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 1.0.2.

janppires
janppires
~ 8 years ago

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 fix, feat they do appear. Should I be worried with this? Is there anyway to configure which type of messages should appear on therelease. change log of github?

Many thanks!

Kent C. Dodds
Kent C. Doddsinstructor
~ 8 years ago

Good quesiton! That functionality is handled by this package: https://github.com/semantic-release/commit-analyzer

janppires
janppires
~ 8 years ago

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?

janppires
janppires
~ 8 years ago

It could also be this one https://github.com/semantic-release/release-notes-generator. But its source code does not have much!

Kent C. Dodds
Kent C. Doddsinstructor
~ 8 years ago

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 :)

Chad Elofson
Chad Elofson
~ 2 years ago

I have this running, but it seems to be keeping my versions below the version I did manually. I think I will need to look at the packages we have added to the project to see where I can fix this issue.

Markdown supported.
Become a member to join the discussionEnroll Today