Migrating from Wercker Classic to Workflows

The classic Wercker stack uses LXC containers as the underlying image format. The Workflows stack is based on Docker containers and is the most current one. It enables developers to use any Docker container from any registry and create any number of pipelines. The Workflows stack comes with a new Command Line Interface (CLI) that allows you to run pipelines locally on your machine.

This article serves as a guide to migrate your existing classic application to the Workflows stack. 

 

Table of Contents

 

Introducing the Workflows stack

The Workflows stack is based on the Docker container format. Docker is a popular format for packaging up your applications and running them on schedulers such as Kubernetes. Though Wercker plays extremely nice with Docker, you are not obligated to do anything with your built containers on the Workflows stack.

Beyond using Docker as the container runtime, the Workflows stack enables you to create any number of pipelines, allowing you to go beyond`build` and `deploy`. Pipelines can be chained and run on completion of previous pipelines. You can even branch your pipelines, thus creating complex Workflows for your automation needs. Finally, the Workflows stack comes with a powerful CLI allowing you to run pipelines locally, enabling a fast feedback-loop and iteration on your application before pushing to the Wercker Cloud. 

 

The migration process

There are two ways to migrate your application to the Workflows stack:

  1. Migrate your application via the migration wizard and update your wercker.yml as directed here.

  2. Delete your application on Wercker and start anew. New applications are Workflows-based by default. 


Moving from official Wercker boxes to Docker

As the Workflows stack uses Docker containers as the underlying environment to run your pipeline jobs, you can use any container from the Docker Hub or other [container registry like Quay or GCR.

This also means there is no longer the need for Wercker officially supported containers. Below you can find a list of official LXC containers previously available on the classic stack, with some recommendations to equivalent Docker containers.

Note that if you can't find what you're looking for, you can always create your own container.

Wercker classic had officially supported LXC containers for the following programming environments; these are sensible defaults for their Docker counter parts.


Third-party Android container

In the yaml itself, you still use the box clause to define your container as you would otherwise. Official containers from the Docker Hub do not need a prefix. So say you want to use the abovementioned Python container you would define this as:

box: python


See this article for more information on using containers.

 

Moving from official Wercker services to Docker

Similar to the language containers mentioned above, you can use any Docker container for your services such as a database or queue. As with the classic stack, services are spun up next to the main programming environment container. Below you can find a list of official LXC containers previously available on the classic stack, with some recommendations to their Docker equivalents.

Wercker classic had officially supported LXC containers for the following services:

See this article on how to connect to your service containers from within your main container.

 

Using Steps

You can still use the steps from the Wercker Step registry as you did before. Remember however that some steps might require certain language dependencies to be present which might no be the case for your Docker container (for instance Python might not be installed, whereas the step uses Python to function). 

 

Legacy Heroku

We no longer support Heroku deploy targets. Instead, you can use the Heroku Deploy step inside of your wercker.yml.