The name of the branch being built
The id of the build being run
The short description of the current commit, e.g. git describe
The id/sha of the commit being built
The message of the commit being built
The email of the commiter
The name of the commiter
The username of the commiter
The id of the project being built
The name of the scm repository being built
Turn debug output on
The directory to use
The name of the service with which the dockercfg should be generated
The path to the encrypted dockercfg file to be used
Set an environment variable (can be used multiple times)
The key path for encrypting secure environment variables.
Do not remove any containers that are run, overrides all other settings
Disable pseudo-tty allocation
Pull images that are already present
Run push steps
The relative services path
The relative steps path
The tag to use
Docker will use existing images when running
jet locally. This may
lead to builds passing locally, and failing remotely on CodeShip. This
is due to the remote environment starting without any prior images. We
recommend removing any locally saved Docker images prior to running
jet steps for a more consistent result to the remote server.
$ jet steps --push (step: tests) ... (step: tests) success ✔ (step: push_service) ...
It is often necessary to test
branch/tag specific steps. To do this, use the
--tag flag to specify a branch or
$ jet steps --tag master $ jet steps --tag staging
A remote build has access to
default environment variables populated from the SCM. You can pass similar data
to test the behavior. A normal practice is to use the
commit-id in a
container tag, for example.
$ jet steps --ci-commit-id 1234ABCD --ci-branch master --ci-committer-name "Jane Doe" --ci-commit-message "A random message from the committer"