The Shippable Blog

Manisha Sahasrabudhe

Manisha Sahasrabudhe

Recent Posts

Triggering a sequential, parameterized build after continuous integration

We are happy to announce the addition of sequential parameterized builds to our feature list. Using this feature, you can trigger a sequence of CI workflows for your projects and even pass parameters from one build to another!

You will want to do this in 2 situations:

- you have build dependencies, and if one codebase changes, you want to trigger builds for all dependent codebases. A great example of this is that you have a base Docker image foo/appBase for your application and all services have a FROM foo/appBase:latest in their Dockerfiles. With this new feature, you can easily trigger builds for all your services if the base image appBase changes.

- your have codebases that need to be triggered sequentially since each build produces parameters required by the next build in the sequence.

This new feature is documented here in greater detail

Let's look at a more detailed example of how this will work in practice.

Triggering a custom webhook after continuous integration

Even with the best continuous integration platform on the planet, you will still have scenarios when you want to trigger custom workflows after your CI finishes. These workflows could be very targeted and should have the ability to be customized based on whether CI passed.

Today, I am going to introduce you to a very versatile feature we added recently - the ability to add a custom webhook to your CI workflows that will be triggered after your build finishes. You can configure this trigger based on several factors, including build result, branch, etc and also include one or more parameters.  

This new feature is documented here in greater detail

Let's look at a simple example to see how this works. I have a project manishas/sample_nodejs and I want to open a GitHub issue in the repository if my build fails. I also want to customize the issue title and description to include a the project name, build number, commit message, and build URL.

Feature roundup: Amazon ECR regions, Service status page, Github tag/release builds, and more!

Feature roundup: Hipchat integration, faster caching, code coverage badge, and much more

We hope you're enjoying using the new Shippable. Now that we're a month past the release and all customers are on the new build platform, we have started knocking off new features at breakneck speed!

Improved integration with Atlassian products

We've added support for commit status of Bitbucket pull requests so you can now view build status for your pull requests from within Bitbucket UI. We also added Hipchat notifications for CI and Pipeline workflows. More on that in a separate blog post to be published later today. 

New caching implementation

Shippable now supports folder level caching so you can cache selectively depending on your needs. The new caching implementation is fast and can save you several minutes in build times! Read more in our documentation about caching.

5 Tips for a Successful Migration

As you probably know, we released an upgraded build system on February 29th. We have started migrating customers to the new platform and some of you have migrated yourself.

While most migrations are transparent, some hit small snags due to their specific build configuration and how it interacts with the new build system. We have put together these 5 tips to help you have a smooth and uneventful upgrade.

Before we start with the tips, I want to call out that caching is currently disabled on our new build platform. Our caching implementation exports and pushes your build container to a Docker registry, but we're seeing very slow execution of these steps. We are already working on an alternate implementation which will let you cache at a folder level. This will be available the week of March 14th. 

Ok, so let's get started with the tips!