2020-11-26 01:09:20 -05:00
---
stage: Verify
2021-08-31 14:10:24 -04:00
group: Pipeline Authoring
2020-11-26 01:09:20 -05:00
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
type: reference
---
2021-07-26 05:09:00 -04:00
# The `.gitlab-ci.yml` file **(FREE)**
2020-11-26 01:09:20 -05:00
2020-12-02 04:09:50 -05:00
To use GitLab CI/CD, you need:
- Application code hosted in a Git repository.
2021-06-28 17:10:13 -04:00
- A file called [`.gitlab-ci.yml` ](index.md ) in the root of your repository, which
2020-12-02 04:09:50 -05:00
contains the CI/CD configuration.
In the `.gitlab-ci.yml` file, you can define:
- The scripts you want to run.
- Other configuration files and templates you want to include.
- Dependencies and caches.
- The commands you want to run in sequence and those you want to run in parallel.
- The location to deploy your application to.
- Whether you want to run the scripts automatically or trigger any of them manually.
The scripts are grouped into **jobs** , and jobs run as part of a larger
**pipeline**. You can group multiple independent jobs into **stages** that run in a defined order.
2021-06-28 17:10:13 -04:00
The CI/CD configuration needs at least one job that is [not hidden ](index.md#hide-jobs ).
2020-12-02 04:09:50 -05:00
You should organize your jobs in a sequence that suits your application and is in accordance with
2021-01-13 13:10:55 -05:00
the tests you wish to perform. To [visualize ](../pipeline_editor/index.md#visualize-ci-configuration ) the process, imagine
2020-12-02 04:09:50 -05:00
the scripts you add to jobs are the same as CLI commands you run on your computer.
When you add a `.gitlab-ci.yml` file to your
repository, GitLab detects it and an application called [GitLab Runner ](https://docs.gitlab.com/runner/ )
runs the scripts defined in the jobs.
A `.gitlab-ci.yml` file might contain:
2020-11-26 01:09:20 -05:00
```yaml
2020-12-02 04:09:50 -05:00
stages:
- build
- test
build-code-job:
stage: build
script:
- echo "Check the ruby version, then build some Ruby project files:"
- ruby -v
- rake
2020-11-26 01:09:20 -05:00
2020-12-02 04:09:50 -05:00
test-code-job1:
stage: test
2020-11-26 01:09:20 -05:00
script:
2020-12-02 04:09:50 -05:00
- echo "If the files are built successfully, test some files with one command:"
- rake test1
test-code-job2:
stage: test
script:
- echo "If the files are built successfully, test other files with a different command:"
- rake test2
2020-11-26 01:09:20 -05:00
```
2020-12-02 04:09:50 -05:00
In this example, the `build-code-job` job in the `build` stage runs first. It outputs
the Ruby version the job is using, then runs `rake` to build project files.
If this job completes successfully, the two `test-code-job` jobs in the `test` stage start
in parallel and run tests on the files.
The full pipeline in the example is composed of three jobs, grouped into two stages,
`build` and `test` . The pipeline runs every time changes are pushed to any
branch in the project.
2020-11-26 01:09:20 -05:00
2020-12-02 04:09:50 -05:00
GitLab CI/CD not only executes the jobs but also shows you what's happening during execution,
just as you would see in your terminal:
2020-11-26 01:09:20 -05:00
2021-03-25 02:09:02 -04:00
![job running ](img/job_running_v13_10.png )
2020-11-26 01:09:20 -05:00
You create the strategy for your app and GitLab runs the pipeline
2020-12-02 04:09:50 -05:00
according to what you've defined. Your pipeline status is also
2020-11-26 01:09:20 -05:00
displayed by GitLab:
![pipeline status ](img/pipeline_status.png )
2020-12-02 04:09:50 -05:00
If anything goes wrong, you can
2021-02-23 16:10:44 -05:00
[roll back ](../environments/index.md#retry-or-roll-back-a-deployment ) the changes:
2020-11-26 01:09:20 -05:00
![rollback button ](img/rollback.png )
2021-06-28 17:10:13 -04:00
[View the full syntax for the `.gitlab-ci.yml` file ](index.md ).