The Shippable Blog

Lately, several folks have asked us about our reasoning behind adding build numbers as the version tags for Docker Hub images. Briefly, our current flow is -

- Pull code from GitHub
- Pull image from Docker Hub (or build from a Dockerfile)
- Run CI in the container
- If CI passes and push to Docker Hub is configured in the yml or Project Settings, push image to Docker Hub with a version tag <image name>:<build number>

The question is - why don't we just tag the image with <image name>:latest? What is the value behind versioning images?

Here at Shippable we love taking customers all the way to continuous deployment. We've detailed a variety of different ways to get there in the past, and today we are going to be bringing out yet another way. Today we'll be showing you how to trigger your Shippable builds, to push your rails apps to Engine Yard.

Before going any further, there are a few pre-reqs:

• An active Engineyard account
• A working rails app on github
• An active Shippable account
• The above rails app being enabled on Shippable
• An application env already setup on Engine Yard

This week, the Shippable team had the opportunity to present 'Modern DevOps with Docker' (describing our internal transformation - see below for more) and engage with the community at ApacheCon 2015 in Austin, TX.  We saw firsthand how the thriving group of dedicated professionals in the Apache community are tackling big challenges across the full tech spectrum.  In addition, while in Austin, we had the chance to connect with the tight-knit and talented DevOps Austin community and learn from their perspectives.  It was an energizing three days.

We introduced our support for docker build a few weeks back - along with it's very own blog post - but we've had requests to support an additional workflow. Starting today, you can docker build an image post-ci. Before we go any further, EVERYTHING mentioned in blog mentioned above is a pre-req to do this. Make sure you do everything mentioned in that blog first, or your post-ci docker build won't work!

Some of you might be wondering why you'd ever want to do this. Well, post-ci building allows you to create a concise docker image that contains only what you need for deployment, and leave out anything that is only required for building/testing. After all, there really isn't a benefit to deploying your build tools to production! However, as there is no upfront way for us to know which files you’d like to put in your “prod” docker image, you must manually specify which files to include. Don't worry though, as it's a simple one-liner. We'll get that in a bit; you first need to tweak your project's settings a little bit further.

Ever wish your build minions could boss around your other minions for you? Well, with the help of the new API, now they can! Today, I'm going to show you how you can have a successful build of one project, kick off a build of a different project. In honor of the new API, we are gonna do it all without leaving the terminal! Warning: You must have a startup or custom plan to use the API.

For illustrative purposes, I've created two repos that contain only shippable.yml files. I'm going to call one project "kicker" and the other project "kicke". The kicker project will kick the kicke project into building, after kicker finishes building successfully. Here is the code for the kicke project's shippable.yml file

install:
  - true
script: 
  - true

Basically, a build that will always run successfully under normal conditions.

Before you do ANYTHING with the api, you're gonna need to get your api token; don't worry though... It's easy! All you have to do is go to your account permissions page and generate a token. We will use this token in the header of our http requests.