We unveiled the latest release of Shippable on February 29th. This release includes over 240 new features and addresses most of the customer feedback we've received over the last few months. Details about the new release are in my blog post here.
A big part of this release is moving to a new yml format that allows for maximum flexibility in configuring your workflows, including access to the Docker CLI in your yml commands.
To ease this transition to the new release, Shippable now includes a built-in yml translator which automatically reads old yml formats and converts them to the new format. This means you do not have to move to the latest format if you don't want to and your projects should continue to just work after your subscription is migrated in the next few days.
There is one caveat to this - if your project is using the UI settings to pull from or push images to a Docker registry, you will need to transition to the new yml format before your subscription can be migrated.
Here is a quick guide explaining how to migrate to the new yml format. (If you want to learn about the new yml format you can read the documentation here.) The built-in yml translator does pretty much the same thing, but you can follow these steps if you want to do this manually.
Please note that this guide is only valid if your subscription is on the Continuous Delivery plan. You will find your plan name on the Billing tab of your Subscription -
Ok, now let's get started.
To begin, these yml tags are unchanged in the new format:
#specifying language runtime. e.g.
Configuring the build: section
Now its time to configure your build settings. The build section of the new yml includes everything you were doing in
before_install, install, before_script, script, after_script, after_success, and after_failure sections. Here is how to migrate these sections:
<commands from before_install section>
<commands from install section>
<commands from before_script section>
<commands from script section>
<commands from after_success section>
<commands from after_script section>
<commands from after_failure section>
<commands from after_script section>
Please note that the sections should be in the sequence listed above and commands in a section should be in the same sequence they were in your original yml.
Notifications are configured differently in the new yml. The new notifications provide a lot of flexibility and can send notifications to multiple places, as well as have more control on notification triggers.
Email notifications are now specified as follows:
- integrationName: email
on_start: true | false(d)
on_success: true | false | change(d)
on_failure: true | false(d) | change
on_pull_request: true(d) | false
The default setting for triggers is indicated by a
(d), which means that if you do not explicitly configure anything for a trigger, we will use this setting. You can also limit the notification type to certain branches using the branches: tag. More on configuring emails is explained in our docs.
To configure Slack or IRC, take a look at these guides:
Migrating Docker options
If your projects do not use Docker options in Project settings, you can skip this section.
If your project is using Docker options in Project Settings (as shown in the image below), you will need to migrate your subscription to the Continuous Delivery plan and start using the new yml format for your projects before Tuesday March 22, 2016. The existing Docker options will be deprecated on that date and your subscription will automatically be migrated to the new platform.
Here are some instructions that will help you migrate Docker options into the new yml format:
Troubleshooting tips and tricks
• If you are using base images from the shippableimages repository, please move to our new images in the drydock repository on Docker Hub. These images have all the pre-requisite packages already installed and also have the latest versions of languages and services.
• If you are using a custom image for your build and pulling images from or pushing to Google Container Registry (GCR) or Amazon's ECR, check out the section on GCR/ECR and Custom images.
- If you are using a custom image for your build, your image needs to define the $HOME environment variable to ensure that ssh config and git sync works as expected. This is explained in the overriding the build image section of the documentation.
• If you need help with figuring out how to move to the new format, open a support issue or send us an email. We're happy to help you through this transition and make everything as effortless as possible.