OpenShift Deployment

This page documents deployments using dpl v1 which is currently the legacy version. The dpl v2 is released, and we recommend useig it. Please see our blog post for details. dpl v2 documentation can be found here.

Travis CI can automatically deploy your OpenShift application after a successful build.

For a minimal configuration, all you need to do is add the following to your .travis.yml:

deploy:
  provider: openshift
  user: "YOU USER NAME"
  password: "YOUR PASSWORD" # can be encrypted
  domain: "YOUR OPENSHIFT DOMAIN"

Currently it is not possible to use a token instead of the password, as these tokens expire too quickly. We are working with the OpenShift team on a solution.

You can also have the travis tool set up everything for you:

travis setup openshift

Keep in mind that the above command has to run in your project directory, so it can modify the .travis.yml for you.

To provide the best service possible, Travis CI has teamed up with OpenShift as a partner and there is an official Travis CI QuickStart to get you going.

Deploy to Applications #

By default, we will try to deploy to an application by the same name as the repository. For example, if you deploy an application from the GitHub repository travis-ci/travis-chat without explicitly specify the name of the application, Travis CI will try to deploy to an OpenShift app named travis-chat.

You can explicitly set the name via the app option:

deploy:
  provider: openshift
  ...
  app: my-app-123

It is also possible to deploy different branches to different applications:

deploy:
  provider: openshift
  ...
  app:
    master: my-app-staging
    production: my-app-production

If these apps belong to different OpenShift domains, you will have to do the same for the domain:

deploy:
  provider: openshift
  ...
  domain:
    master: ...
    production: ...
  app:
    master: my-app-staging
    production: my-app-production

Deploy Specific Branches #

If you have branch specific options, as shown above, Travis CI will automatically figure out which branches to deploy from. Otherwise, it will only deploy from your master branch.

You can also explicitly specify the branch to deploy from with the on option:

deploy:
  provider: openshift
  ...
  on: production

Alternatively, you can also configure it to deploy from all branches:

deploy:
  provider: openshift
  ...
  on:
    all_branches: true

Builds triggered from Pull Requests will never trigger a deploy.

Deploy build artifacts #

After your tests ran and before the deploy, Travis CI will clean up any additional files and changes you made.

Maybe that is not what you want, as you might generate some artifacts (think asset compilation) that are supposed to be deployed, too. There is now an option to skip the clean up:

deploy:
  provider: openshift
  ...
  skip_cleanup: true

Conditional releases #

You can deploy only when certain conditions are met. See Conditional Releases with on:.

The .gitignore method #

As this deployment strategy relies on git, be mindful that the deployment will honor .gitignore.

If your .gitignore file matches something that your build creates, use before_deploy to change its content.

Run Commands Before or After Deploy #

Sometimes you want to run commands before or after deploying. You can use the before_deploy and after_deploy stages for this. These will only be triggered if Travis CI is actually deploying.

before_deploy: "echo 'ready?'"
deploy:
  ..
after_deploy:
  - ./after_deploy_1.sh
  - ./after_deploy_2.sh

Deployment Branch #

OpenShift can be configured to deploy from a branch different from the default master via rhc app-configure --deployment-branch mybranch.

If you’ve done this to your application, specify this desired branch with deployment_branch:

deploy:
  provider: openshift
  ...
  deployment_branch: mybranch