Become a member
to unlock all features

Level Up!

Access all courses & lessons on egghead today and lock-in your price for life.


    Automatically Releasing with TravisCI


    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.



    Become a Member to view code

    You must be a Pro Member to view code

    Access all courses and lessons, track your progress, gain confidence and expertise.

    Become a Member
    and unlock code for this lesson
    orLog In




    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    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.