doc/ci/quick_start/_index.md
{{< details >}}
{{< /details >}}
This tutorial shows you how to configure and run your first CI/CD pipeline in GitLab.
If you are already familiar with basic CI/CD concepts, you can learn about common keywords in Tutorial: Create a complex pipeline.
Before you start, make sure you have:
If you don't have a project, you can create a public project for free on https://gitlab.com.
To create and run your first pipeline:
Ensure you have runners available to run your jobs.
If you're using GitLab.com, you can skip this step. GitLab.com provides instance runners for you.
Create a .gitlab-ci.yml file
at the root of your repository. This file is where you define the CI/CD jobs.
When you commit the file to your repository, the runner runs your jobs. The job results are displayed in a pipeline.
In GitLab, runners are agents that run your CI/CD jobs.
If you're using GitLab.com, you can skip this step. GitLab.com provides instance runners for you.
To view available runners:
As long as you have at least one runner that's active, with a green circle next to it, you have a runner available to process your jobs.
If you don't have access to these settings, contact your GitLab administrator.
If you don't have a runner:
shell executor.When your CI/CD jobs run, in a later step, they will run on your local machine.
.gitlab-ci.yml fileNow create a .gitlab-ci.yml file. It is a YAML file where
you specify instructions for GitLab CI/CD.
In this file, you define:
To create a .gitlab-ci.yml file in your project:
In the top bar, select Search or go to and find your project.
In the left sidebar, select Code > Repository.
Above the file list, select the branch you want to commit to.
If you're not sure, leave master or main.
Then, in the upper-right corner, select the plus icon ({{< icon name="plus" >}}) and New file:
For the Filename, type .gitlab-ci.yml and in the larger window,
paste this sample code:
build-job:
stage: build
script:
- echo "Hello, $GITLAB_USER_LOGIN!"
test-job1:
stage: test
script:
- echo "This job tests something"
test-job2:
stage: test
script:
- echo "This job tests something, but takes more time than test-job1."
- echo "After the echo commands complete, it runs the sleep command for 20 seconds"
- echo "which simulates a test that runs 20 seconds longer than test-job1"
- sleep 20
deploy-prod:
stage: deploy
script:
- echo "This job deploys something from the $CI_COMMIT_BRANCH branch."
environment: production
This example shows four jobs: build-job, test-job1, test-job2, and deploy-prod.
The comments listed in the echo commands are displayed in the UI when you view the jobs.
The values for the predefined variables
$GITLAB_USER_LOGIN and $CI_COMMIT_BRANCH are populated when the jobs run.
Select Commit changes.
The pipeline starts and runs the jobs you defined in the .gitlab-ci.yml file.
Now take a look at your pipeline and the jobs within.
Go to Build > Pipelines. A pipeline with three stages should be displayed:
View a visual representation of your pipeline by selecting the pipeline ID (#676 in this example):
View details of a job by selecting the job name. For example, deploy-prod:
You have successfully created your first CI/CD pipeline in GitLab. Congratulations!
Now you can get started customizing your .gitlab-ci.yml and defining more advanced jobs.
.gitlab-ci.yml tipsHere are some tips to get started working with the .gitlab-ci.yml file.
For the complete .gitlab-ci.yml syntax, see the full CI/CD YAML syntax reference.
.gitlab-ci.yml file.stage describes the sequential execution of jobs.
If there are runners available, jobs in a single stage run in parallel.needs keyword to run jobs out of stage order,
to increase pipeline speed and efficiency.rules keyword to specify when to run or skip jobs.
The only and except legacy keywords are still supported, but can't be used
with rules in the same job.cache
and artifacts. These keywords are ways to store
dependencies and job output, even when using ephemeral runners for each job.default keyword to specify additional
configurations that are applied to all jobs. This keyword is often used to define
before_script and after_script
sections that should run on every job.Migrate from: