Steps are self-contained bash scripts or compiled binaries for accomplishing specific automation tasks, defined in the wercker.yml file of your application. Steps can be written manually or borrowed from the community via the Steps Registry.
An example of a step with parameters:
build: steps: - email@example.com: package: jshint strict-ssl: false - npm-test
This will pass two parameters to the
npm install step:
Apart from predefined steps there are also
custom steps , also known as inline steps. Custom steps allow you to run bash scripts directly within your Pipelines:
# A custom script step, name value is used in the UI # and the code value contains the command that get executed - script: name: echo python information code: | echo "python version $(python --version) running" echo "pip version $(pip --version) running"
This example echos back the
pip versions to us. Note that the result of these commands is available in the Wercker user interface and will be exposed as a build step under the name
echo python information.
Wercker also has the notion of after-steps, which are ideally suited for notifications.
Certain steps are baked into the Wercker CLI. These are called Internal Steps. Read more about them here.
Some tools need to be in a certain directory to work; bundle-install for example will look for a Gemfile in the current directory and install the gems from that Gemfile. With Wercker it is possible to change the working directory for all steps. I is not necessary for the step developers to add extra code.
To change the working directory of a step you need to add a cwd element to the step. You can specify a relative path (relative from $WERCKER_ROOT) or an absolute path. Use of environment variables is possible.
build: steps: - bundle-install: cwd: src/
If you are unable to find a Step that you require on the Steps Registry, you can create your own. Deploying your step to the Steps Registry will allow others to use your Step.