Migrate from deploy to run
On This Page
Introduction
A configuration file that uses the deprecated deploy
step must be converted, and all instances of the deploy
step must be removed, regardless of whether or not parallelism is used in the job.
-
Does your job have parallelism of 1? Swap out the
deploy
key for therun
key. Nothing more is needed to migrate. -
Does your job have parallelism > 1? There is no direct replacement for the
deploy
step if you are usingparallelism > 1
in your job. The recommendation is to create two separate jobs within one workflow - a test job, and a deploy job. The test job will run the tests in parallel, and the deploy job will depend on the test job. The test job hasparallelism > 1
, and the deploy job will have the command from the previousdeploy
step replaced withrun
and no parallelism. Please see examples in this guide.
Parallelism > 1
The following is an example of replacing the deprecated deploy
step in a configuration file that has parallelism > 1
.
The code in the first example below is deprecated. Do not copy. |
# Example of deprecated syntax, do not copy
version: 2.1
jobs:
deploy-step-job:
docker:
- image: cimg/base:stable
parallelism: 3
steps:
- checkout
- run:
name: "Say hello"
command: "echo Hello, World!"
- run:
name: "Write random data"
command: openssl rand -hex 4 > rand_${CIRCLE_NODE_INDEX}.txt
- run:
name: "Emulate doing things"
command: |
if [[ "$CIRCLE_NODE_INDEX" != "0" ]]; then
sleep 30
fi
- deploy: #deprecated deploy step, do not copy
command: |
echo "this is a deploy step which needs data from the rand"
cat rand_*.txt
workflows:
deploy-step-workflow:
jobs:
- deploy-step-job
If you are entirely reliant on external resources (for example, Docker containers pushed to a registry), you can extract the deploy
step above as a job, which requires doing-things-job
to complete. doing-things-job
uses parallelism of 3, while deploy-step-job
performs the actual deployment. See example below.
version: 2.1
jobs:
doing-things-job:
docker:
- image: cimg/base:stable
parallelism: 3
steps:
- checkout
- run:
name: "Say hello"
command: "echo Hello, World!"
- run:
name: "Write random data"
command: openssl rand -hex 4 > rand_${CIRCLE_NODE_INDEX}.txt
- run:
name: "Emulate doing things"
command: |
if [[ "$CIRCLE_NODE_INDEX" != "0" ]]; then
sleep 30
fi
# create a new job with the deploy step in it
deploy-job:
docker:
- image: cimg/base:stable
steps:
- run: # change "deploy" to "run"
command: |
echo "this is a deploy step"
workflows:
deploy-step-workflow:
jobs:
- doing-things-job
# add your new job and make it depend on the
# "doing-things-job"
- deploy-job:
requires:
- doing-things-job
Using workspaces
If files are needed from doing-things-job
in the deploy-job
, use workspaces. This enables sharing of files between two jobs so that the deploy-job
can access them. See example below.
version: 2.1
jobs:
doing-things-job:
docker:
- image: cimg/base:stable
parallelism: 3
steps:
- checkout
- run:
name: "Say hello"
command: "echo Hello, World!"
- run:
name: "Write random data"
command: openssl rand -hex 4 > rand_${CIRCLE_NODE_INDEX}.txt
- run:
name: "Emulate doing things"
command: |
if [[ "$CIRCLE_NODE_INDEX" != "0" ]]; then
sleep 30
fi
# save the files your deploy step needs
- persist_to_workspace:
root: . # relative path to our working directory
paths: # file globs which will be persisted to the workspace
- rand_*
deploy-job:
docker:
- image: cimg/base:stable
steps:
# attach the files you persisted in the doing-things-job
- attach_workspace:
at: . # relative path to our working directory
- run:
command: |
echo "this is a deploy step"
workflows:
deploy-step-workflow:
jobs:
- doing-things-job
- deploy-job:
requires:
- doing-things-job
This is effectively using a "fan-in" workflow which is described in detail on the workflows page.
Support for the deprecated deploy step will eventually be removed. Ample time will be given for customers to migrate their configuration. |
Help make this document better
This guide, as well as the rest of our docs, are open source and available on GitHub. We welcome your contributions.
- Suggest an edit to this page (please read the contributing guide first).
- To report a problem in the documentation, or to submit feedback and comments, please open an issue on GitHub.
- CircleCI is always seeking ways to improve your experience with our platform. If you would like to share feedback, please join our research community.
Need support?
Our support engineers are available to help with service issues, billing, or account related questions, and can help troubleshoot build configurations. Contact our support engineers by opening a ticket.
You can also visit our support site to find support articles, community forums, and training resources.
CircleCI Documentation by CircleCI is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.