This article is about Codeship Pro.

Getting Started With Codeship Pro Part 5

Estimated Reading Time: 4 mins

The source for the tutorial is available on Github as codeship/ci-guide and you can clone it via

git clone

Getting Started With Codeship Pro (Part 5)

Now that we’ve covered the basic pieces of the service, we should take a few minutes and cover two additional features that make for more flexible and powerful CI/CD workflows for your team.


Next up, let’s take a look at caching. When you use caching, we’ll push your image out to a private, secure S3 bucket with access credentials unique to your project. Then, on your next build, we’ll quickly check your Dockerfile to see if anything has changed. If nothing has changed - meaning, if building the Dockerfile would result in the exact same image as last time - we’ll reuse the cached image. This is a layer by layer cache, so we’ll reuse as much of the image as we can before rebuilding the rest of the image once we encounter a change.

Let’s open up our codeship-services.yml file and make a change to enable caching.

    image: myapp
    dockerfile: Dockerfile
    - redis
    - postgres
    - ./tmp:/app
  cached: true

Now, let’s push our build so that it runs and sets our cache.

Of course, to see our cache in action we’ll have to push another build using the same image so that we can actually use the cache - so let’s comment out part of our codeship-steps.yml file just for this example and push up a (second) new build.

- type: parallel
    - name: checkrb
      service: demo
      command: bundle exec ruby check.rb
    - name: test
      service: demo
      command: bundle exec ruby test.rb
    # - type: serial
    #   steps:
    #   - name: volumes_in
    #     service: demo
    #     command: bundle exec ruby write.rb
    #   - name: volumes_out
    #     service: demo
    #     command: bundle exec ruby read.rb

- type: serial
    - name: dockerhub_push
      service: checkrb
      type: push
      image_name: account/repo
      encrypted_dockercfg_path: dockercfg.encrypted

Once the new build runs, we can check our log output and see our cache in action.

Caching working log output.

Caching is a really powerful way to speed your builds up. We also have a great article on optimizing your builds overall, as well as making sure your Dockerfile is designed with caching in mind. You can read that here.

Tests Per Branch

Now I want to take a look at a bit of the flexibility you can implement around running your tests.

Let’s go back to our codeship-steps.yml file and look at the command where we run our tests.

On our step, let’s add a new line: tag: master

This tag tells Codeship to only run this tag on the master branch. You can imagine creating branches that run all your tests (before deployments, for instance), branches that only run front-end tests or tests for certain apis (/api/_ for instance)… and a ton of other combinations that will streamline your workflows and keep developers productive.

Learn More!

From here, there’s still a ton more you can learn to optimize your builds, troubleshoot your problems and build more complex and productive workflows.

We recommend our blog, our documentation, our community forum, and our webinars to keep learning more.

It’s important to get to a working build as soon as possible when you start your new CI/CD process with Codeship Pro. From there, take some time with your team every few weeks or every few months to find ways to optimize, save time, keep the developers coding with fewer waiting periods and improve your application and Docker image efficiency.

Need More Help?

Get in touch if you need more help, or post on Stack Overflow using the tag #Codeship.

  • Ask The Helpdesk A Question
  • Code Examples And Sample Projects
    • Was This Article Helpful?