Skip to content

Continuously deploying your (free) OpenShift site with Travis CI

The LibertyJS website is hosted on RedHat’s OpenShift, which is essentially RedHat Heroku. Meaning, it’s really easy to define a language, push to a git remote, and voila! There’s your website. Plus, you know, free (ish).

While that’s certainly fantastic, getting pull requests, merging, but then having to do a repetitive process of “git fetch && git rebase origin/master && grunt build …” got old.

Enter: Travis CI!

Travis CI is a continuous integration tool that is kind of stupidly easy to use (well, almost, we’ll see). The ‘.org’ version is free for open source projects (like LibertyJS), while ‘.com‘ is for private repositories.

Travis CI + OpenShift

OpenShift has an ALMOST perfect guide to deploying on TravisCI, but here’s what I did, starring the key “AHA!” moment.

  1. OpenShift project was already created (the rhc gem walks you through that)
  2. I needed to make my membership in LibertyJS public, so that Travis could see the project when I logged in
  3. Turned ‘on’ Travis for the project from the profile page (https://travis-ci.org/profile/[your github name])
  4. Added a .travis.yml to the project, specify language and version
  5. Travis runs my tests, YAY!
  6. Ran ‘travis setup openshift’, which takes you through a convenient “what’s your username/password” walk through and drops in the deploy information
  7. Set up my “after_success” steps to do exactly what I was doing locally to deploy
  8. Flail violently when it doesn’t work
  9. ****Discover that when Openshift says “domain,” they don’t mean the domain where the app lives, they mean the domain, like the user namespace where that url comes from (in my case, project name is libertyjs, domain is pselle)****
  10. CELEBRATE

And here’s the way I figured it out: I searched for provider: openshift on github (since I knew something was wrong with the deploy line from the failures in Travis) to see wth OpenShift meant by “domain.” I also learned a good number of folk didn’t encrypt their passwords … eep!

So painful, but definitely a worthy learning experience, if I did feel a little dumb for being unable to figure it out for a while.

8 Replies to “Continuously deploying your (free) OpenShift site with Travis CI”

  1. Hi there

    Good article. I had exactly the same arms-flailing with the domain stuff. How do you go about giving your OpenShift releases a version number? I was hoping to do my releases from a tag like I do with npm releases, but the robots seems to refuse to bend to my will.

    Thanks

    S

      1. That would work, but one has to remember to bump the version number before pushing the release and you’re soon into territory whereby you might as well not bothered with automated deployment. And besides, if you create your tags with npm version, it does bumps the version number and tag it for you.

        I suspect there will be a solution (I eventually found it with npm – https://github.com/riggerthegeek/steeplejack/blob/master/.travis.yml) so I will perservere.

        One thing I did notice though – if OpenShift fails to start the process, Travis doesn’t mark this as a failed build. Look at line 1,439 onwards on https://travis-ci.org/riggerthegeek/kitbag-api/builds/40939572. OS marks as failed, but Travis says “thanks, I’m happy”

        S

        1. ah ah, yes you meant versioning by the robots, which yes I am way in favor of. What in your travis does it via npm? The provider: line? Very interesting.

          Ooh, and application failed to start should totally be a non-zero exit on OpenShift’s part. That might be worth raising with them.

  2. Hi Pam, thanks for mentioning that “domain” means a different thing for Travis CI / OpenShift. I tried it a thousand times with “abc-xyz.rhcloud.com” but it was always failing. Because of your blog post I entered “xyz” and tada! Success! 🙂

        1. Hey Rich. Two things:

          Visiting your site looks like a redirect loop? Something is up in general there.
          snd-onairtest.rhcloud.com

          I don’t see anything here: http://docs.travis-ci.com/user/build-configuration/ about before_deploy, but I’m sure it’s a real thing.

          Sorry I can’t be of more help, I’m mostly thrilled in general when Travis “just works.” I also haven’t seen someone use two different providers in one Travis instance, that’s new to me/didn’t know you could do that

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.