The Freestyle step is designed so you can execute a series of commands in a container. Select an image to start a container, then you can specify a working directory, and commands. If you do not specify a working directory or commands, the step runs the organic commands specified by the image.
Using complex commands in the untyped step requires use of YAML block scalars.
||The free-text display name of the step.||Optional|
||A basic, free-text description of the step.||Optional|
||Parent group of this step. See using stages for more information.||Optional|
||The image from which the executable container is created. It can be an explicit ID of a Docker image, or a variable that references a Build or Push step.||Required|
||The directory from which the commands are executed. It can be an explicit path in the container’s file system, or a variable that references another step. The default
||One or more commands to execute in a shell in the container, as array of strings.||Optional|
||docker CMD arguments to use along with the container entrypoint. can be string or array of strings.||Optional|
||override the default container entrypoint. can be string or array of strings.||Optional|
||A set of environment variables for the container.||Optional|
||If a step fails, and the process is halted. The default value is
||One or more volumes for the container. All volumes must be mounted from the existing shared volume (see details below)||Optional|
||Define a set of conditions that need to be satisfied in order to execute this step. You can find more information in the Conditional Execution of Steps article.||Optional|
||Define operations to perform upon step completion using a set of predefined Post-Step Operations.||Optional|
||Define retry behavior as described in Retrying a step.||Optional|
- Working Directory.
When using the original container entrypoint, you can use the
cmd field to specify additional agruments to be used with the entrypoint. This can be a string, or an array of strings. For example:
image: mwendler/cowsay cmd: - "Hello"
is equivalent to running
docker run mwendler/cowsay Hello which is equivalent to running
cowsay Hello inside the container.
You can override the container’s default entrypoint using the
entry_point field. This can be a string, or an array of strings. For example:
image: mwendler/cowsay entry_point: - echo - Hello
When you use the
commands field, it will override the container original
entrypoint and will execute the commands in a shell inside the container.
The provided commands are concatenated into a single command using the shell’s
; operator, and are run using the default shell
/bin/sh as an entry point.
Additional settings that are set only when using commands are
set -e, and the
Commands and Entry point
If you want to retain the original entrypoint, do not use the
However, this example:
image: mwendler/cowsay commands: - "Hello"
will cause and error because the engine will attempt to run the command
Hello in a shell inside the container, and the command
Hello is not a valid command.
In order to use the
commands form with an
entrypoint enabled container, you can add the commands from the entrypoint to the list of commands, like so:
image: mwendler/cowsay commands: - cowsay "Hello"
If you are familiar with Codefresh pipelines you should know that all freestyle steps automatically share a volume mounted at
/codefresh/volume which can be used to transfer data (e.g. dependencies and test results) from each step to the next.
This volume is automatically mounted by Codefresh and needs no configuration at all. All you have to do to access it, is read/write the
/codefresh/volume folder from your application. This folder also includes by default the source code of the git repository connected to the pipeline (at the
You can use the
volumes property to create your own custom volumes that can be mounted in different folders. For security reasons however all source volume data (i.e. the “host” folder) still needs to be bound with
/codefresh/volume or any of its subdirectories:
Attempting to mount a folder outside of
/codefresh/volume will result in an error.
Simple volume example
Let’s assume that your application expects to find a configuration folder at
/config. The folder however that contains the needed files in GIT is under
my-app-repo/my-sample-config. When the application is checked out the files actually reside at
You can still run your application without any code changes by doing the following bind:
title: Running my application with custom volume image: my-docker-app:latest volumes: - ./my-app-repo/my-sample-config:/config # host path is relative to /codefresh/volume
my-docker-app application will run and find all its needed files at
Notice that we use a relative path here but even if you used an absolute one (
/my-app/my-sample-config) the result would be the same because Codefresh does not allow you to bind anything outside the shared Codefresh volume.
Injecting custom folders in a running container
Here is another example pipeline with two steps. The first one creates a custom config file in the shared Codefresh volume (that is always available) at
/codefresh/volume/my-config. The second step reads the config file at a different folder in
version: '1.0' steps: CreateCustomConfiguration: title: Creating configuration image: alpine commands: - mkdir -p /codefresh/volume/my-config - echo "foo=bar" > /codefresh/volume/my-config/custom.txt - ls /codefresh/volume/my-config InjectConfiguration: title: Reading configuration image: alpine commands: - ls /codefresh/volume/my-config # Codefresh default volume shared between all steps - ls /my-own-config-folder-injected # Special volume just for this container - cat /my-own-config-folder-injected/custom.txt volumes: - ./my-config:/my-own-config-folder-injected
When the second steps runs, the
custom.txt file is available both at
/codefresh/volume/my-config (the shared volume of all steps) as well as the
/my-own-config-folder-injected folder which was mounted specifically for this step.