- Before you begin
- Create a step
- Configure a pipeline to use the step
- Add multiple steps to a job
- Refactor your step
- Use a remote step
Tutorial: Set up CI/CD steps
This tutorial shows you how to create and use steps in your pipelines.
Steps are reusable and composable pieces of a job. Each step defines structured inputs and outputs that can be consumed by other steps. You can configure steps in local files, GitLab.com repositories, or any other Git source.
In this tutorial, use the GitLab CLI (glab
) to:
- Create a step that outputs “hello world”.
- Configure a pipeline to use the step.
- Add multiple steps to a job.
- Use a remote step to echo all the outputs.
Before you begin
- You must install and sign in to the GitLab CLI (
glab
). - On GitLab.com and self-managed in GitLab 17.3 and later, you must include the
image: registry.gitlab.com/gitlab-org/step-runner:v0
runner image in the.gitlab-ci.yml
file.
Create a step
First, create a step with:
- An
exec
type. - A
command
that’s started by the executive API of the system.
-
Create a GitLab project named
zero-to-steps
in your namespace:glab project create zero-to-steps
-
Go to the root of the project repository:
cd zero-to-steps
-
Create a
step.yml
file.touch step.yml
-
Use a text editor to add a specification to the
step.yml
:spec: inputs: who: default: world type: string
-
spec
has one input calledwho
. - The input
who
is optional because there is a default value.
-
-
To add an implementation to the
step.yml
, add a second YAML document afterspec
, with theexec
key:spec: inputs: who: default: world type: string --- exec: command: - bash - -c - "echo hello ${{ inputs.who }}"
The triple em dash (---
) separates the file into two YAML documents:
- The first document is the specification, like a function signature.
- The second document is the implementation, like a function body.
The bash
and -c
arguments start a Bash shell and take the script input from the command line arguments.
In addition to shell scripts, you can use command
to execute programs like docker
or terraform
.
The "echo hello ${{ input.name }}"
argument includes an expression inside ${{
and }}
.
Expressions are evaluated at the last possible moment and have access to the current execution context.
This expression accesses inputs
and reads the value of who
:
- If
who
is provided by the caller, that value is substituted for the expression. - If
who
is omitted, then the defaultworld
is substituted for the expression instead.
Configure a pipeline to use the step
-
In the root of the repository, create a
.gitlab-ci.yml
file:touch .gitlab-ci.yml
-
In the
.gitlab-ci.yml
, add the following job:hello-world: variables: STEPS: expand: false value: | - name: hello_world step: . image: registry.gitlab.com/gitlab-org/step-runner:v0 script: - /step-runner ci
- The steps are given in an environment variable called
STEPS
.STEPS
is a list of step invocations.- Each invocation is given a
name
so you can reference the outputs in later steps. - Each invocations specifies a
step
to run. A local reference (.
) points to the root of the repository.
- Each invocation is given a
- The job script invokes
step-runner ci
which is in thestep-runner:v0
image.
For an example of how this code should look in your repository, see this example.
- The steps are given in an environment variable called
-
Commit both files and push the project repository. This triggers a pipeline that runs the job:
git add . git commit -m 'Part 1 complete' git push --set-upstream origin master glab ci status
-
Follow the job under “View Logs” until the pipeline completes. Here’s an example of a successful job:
$ /step-runner ci hello world trace written to step-results.json Cleaning up project directory and file based variables Job succeeded
run
keyword is implemented.
See the run
keyword epic.You’ve now created and used your first step!
Add multiple steps to a job
You can have more than one step in a job.
-
In the
.gitlab-ci.yml
file, add another step calledhello_steps
to your job:hello-world: variables: STEPS: expand: false value: | - name: hello_world step: . - name: hello_steps step: . inputs: who: gitlab steps image: registry.gitlab.com/gitlab-org/step-runner:v0 script: - /step-runner ci
This
hello_steps
step provides a non-default inputwho
ofgitlab steps
.For an example of how this code should look in your repository, see this example.
-
Commit and push the changes:
git commit -a -m 'Added another step' git push glab ci status
-
In the terminal, select View Logs and follow the pipeline until it completes. Here’s an example of a successful output:
$ /step-runner ci hello world hello gitlab steps trace written to step-results.json Cleaning up project directory and file based variables Job succeeded
Refactor your step
To refactor your steps, move them from the .gitlab-ci.yml
to a dedicated file:
To refactor your steps by moving them from CI Config into a dedicated file:
-
Move the first step you created to a directory called
hello
:mkdir hello mv step.yml hello/
-
Create a new step at the root of the repository.
touch step.yml
-
Add the following configuration to the new
step.yml
:spec: {} --- steps: - name: hello_world step: ./hello - name: hello_steps step: ./hello inputs: who: gitlab steps
This new step has no inputs, so the
spec
is empty ({}
). It is asteps
type, which has the same syntax as steps in.gitlab-ci.yml
. However, the local reference now points to your step in thehello
directory. -
To use the new step, modify
.gitlab-ci.yml
:hello-world: variables: STEPS: expand: false value: | - name: hello_everybody step: . image: registry.gitlab.com/gitlab-org/step-runner:v0 script: - /step-runner ci
Now your job invokes only the new step with no inputs. You’ve refactored the details of the job into a separate file.
For an example of how this code should look in your repository, see this example.
-
Commit and push the changes:
git add . git commit -m 'Refactored step config' git push glab ci status
- In the terminal, select View Logs.
-
To verify that the refactored step performs the same function as the step you first created, view the log output. The log output should match the output of the step you created previously. Here’s an example:
$ /step-runner ci hello world hello gitlab steps trace written to step-results.json Cleaning up project directory and file based variables Job succeeded
Add an output to the step
Add an output to your hello
step.
-
In
hello/step.yml
, add anoutputs
structure to thespec
:spec: inputs: who: default: world type: string outputs: greeting: type: string --- exec: command: - bash - -c - "echo greeting=\"hello ${{ inputs.who }}\" | tee ${{ output_file }}"
- In this
spec
, you’ve defined a single outputgreeting
without a default. Because there is no default, the outputgreeting
is required. - Outputs are written to a file
${{ output_file }}
(provided at run time) in the formkey=value
. - This step runs
echo greeting=\"hello ${{ inputs.name }}\"
and sends the output to the logs and the output file (tee ${{ output_file }}
).
- In this
-
In
step.yml
, add an output to the step:spec: outputs: all_greetings: {} --- steps: - name: hello_world step: ./hello - name: hello_steps step: ./hello inputs: who: gitlab steps outputs: all_greetings: "${{ steps.hello_world.outputs.greeting }} and ${{ steps.hello_steps.outputs.greeting }}"
You’ve now added an output to this step called all_greetings
.
This output shows the use of a new expression syntax: ${{ steps.hello_world.outputs.greeting }}
.
This expression reads the outputs
of the two sub-steps, hello_world
and hello_steps
.
Both sub-step outputs are concatenated into a single string output.
Use a remote step
Before you commit and run your code, add another step to your job to see the final all_greetings
output of your main step.yml
.
This step invocation references a remote step named echo-step
.
The echo step takes a single input echo
, prints it to the logs, and outputs it as echo
.
-
Edit the
.gitlab-ci.yml
:hello-world: variables: STEPS: expand: false value: | - name: hello_everybody step: . - name: all_my_greetings step: gitlab.com/gitlab-org/ci-cd/runner-tools/echo-step@main inputs: echo: "all my greetings say ${{ steps.hello_everybody.outputs.all_greetings }}" image: registry.gitlab.com/gitlab-org/step-runner:v0 script: - /step-runner ci
For an example of how this code should look in your repository, see this example.
-
Commit and push the changes:
git commit -a -m 'Added outputs' git push glab ci status
-
Follow the job under “View Logs” until the pipeline completes. Here’s an example of a successful output:
$ /step-runner ci greeting=hello world greeting=hello gitlab steps echo=all my greetings say hello world and hello gitlab steps trace written to step-results.json Cleaning up project directory and file based variables Job succeeded
That’s it! You’ve just created and implemented steps in your pipeline. For more information about the syntax for steps, see CI/CD Steps.