GitLab CI basics - Commands & Configuration

Introduction

GitLab CI helps you automatically test and deploy your code whenever you make changes. It saves time by running tasks for you without manual work.

When you want to check your code for errors every time you save changes.

When you want to automatically deploy your website after updating the code.

When you want to run tests to make sure new features do not break existing ones.

When you want to build your software in a clean environment every time.

When you want to share your build and test process with your team.

Config File - .gitlab-ci.yml

.gitlab-ci.yml

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Building the project..."
    - mkdir -p build
    - echo "Build complete" > build/status.txt

test_job:
  stage: test
  script:
    - echo "Running tests..."
    - if [ -f build/status.txt ]; then echo "Tests passed"; else echo "Tests failed"; exit 1; fi

deploy_job:
  stage: deploy
  script:
    - echo "Deploying application..."
    - echo "Deployment done"

This file defines three stages: build, test, and deploy.

Each job runs commands in order: build_job creates a build folder and a status file, test_job checks if the build was successful, and deploy_job simulates deployment.

GitLab CI runs these jobs automatically when you push code.

Commands

Initialize a new Git repository in your project folder to start tracking changes.

Terminal

git init

Expected Output

Initialized empty Git repository in /home/user/project/.git/

Add the GitLab CI configuration file to the staging area so it will be included in the next commit.

Terminal

git add .gitlab-ci.yml

Expected Output

No output (command runs silently)

Save the staged changes with a message describing the addition of the CI configuration.

Terminal

git commit -m "Add GitLab CI configuration"

Expected Output

[master (root-commit) abcdef1] Add GitLab CI configuration

 1 file changed, 15 insertions(+)

 create mode 100644 .gitlab-ci.yml

→

-m - Add a commit message inline

Link your local repository to the remote GitLab repository where the code and CI will run.

Terminal

git remote add origin https://gitlab.com/example-user/example-project.git

Expected Output

No output (command runs silently)

Push your local commits to the remote GitLab repository and set the upstream branch for future pushes.

Terminal

git push -u origin master

Expected Output

Enumerating objects: 5, done.

Counting objects: 100% (5/5), done.

Writing objects: 100% (5/5), 1.23 KiB | 1.23 MiB/s, done.

Total 5 (delta 0), reused 0 (delta 0), pack-reused 0

To https://gitlab.com/example-user/example-project.git

 * [new branch]      master -> master

Branch 'master' set up to track remote branch 'master' from 'origin'.

→

-u - Set upstream tracking for the branch

Key Concept

If you remember nothing else from this pattern, remember: GitLab CI runs the jobs you define in .gitlab-ci.yml automatically when you push your code.

Common Mistakes

Not naming the file exactly .gitlab-ci.yml

GitLab only recognizes the CI configuration if the file is named .gitlab-ci.yml in the root folder.

Always name the file .gitlab-ci.yml and place it in the root of your project.

Pushing code without committing the .gitlab-ci.yml file

If the CI file is not committed and pushed, GitLab cannot run the pipeline.

Add and commit the .gitlab-ci.yml file before pushing to GitLab.

Forgetting to link the local repo to the remote GitLab repo

Without the remote link, pushing code to GitLab is not possible, so CI won't run.

Use git remote add origin with the correct GitLab URL before pushing.

Summary

Create a .gitlab-ci.yml file to define your build, test, and deploy jobs.

Commit and push this file to your GitLab repository to trigger the CI pipeline.

GitLab automatically runs the jobs in the order of stages when you push code.

Practice

1. What is the main purpose of the .gitlab-ci.yml file in GitLab CI?

easy

A. To create branches automatically

B. To store the source code of the project

C. To configure user permissions in GitLab

D. To define the stages and jobs for automated tasks like build and test

Solution

1. Step 1: Understand the role of .gitlab-ci.yml

   This file is used to tell GitLab CI what tasks to run automatically, such as building or testing code.

2. Step 2: Identify what the file does not do

   It does not store code, manage permissions, or create branches; those are handled elsewhere.

3. Final Answer:

   To define the stages and jobs for automated tasks like build and test -> Option D

4. Quick Check:

   .gitlab-ci.yml defines jobs and stages [OK]

Hint: Remember: .gitlab-ci.yml controls automation steps [OK]

Common Mistakes:

• Confusing .gitlab-ci.yml with source code files
• Thinking it manages user permissions
• Assuming it creates branches automatically

2. Which of the following is the correct way to define a job named test in .gitlab-ci.yml?

easy

A. job test {
run: echo "Running tests"
}

B. test:
script:
- echo "Running tests"

C. job:
name: test
command: echo "Running tests"

D. task test:
commands:
- echo "Running tests"

Solution

1. Step 1: Recall GitLab CI job syntax

   A job is defined by its name followed by a script section listing commands to run.

2. Step 2: Compare options to correct YAML format

   test: script: - echo "Running tests" uses correct YAML with job name and script list. Others use incorrect keywords or syntax.

3. Final Answer:

   test: script: - echo "Running tests" -> Option B

4. Quick Check:

   Job name + script list = correct job definition [OK]

Hint: Job name + script list is the YAML way to define jobs [OK]

Common Mistakes:

• Using curly braces or incorrect keywords like 'job' or 'task'
• Not using a list for script commands
• Incorrect indentation or missing colons

3. Given this .gitlab-ci.yml snippet:

stages:
  - build
  - test

build_job:
  stage: build
  script:
    - echo "Building"
test_job:
  stage: test
  script:
    - echo "Testing"

What will be the order of job execution?

medium

A. Both jobs run at the same time

B. test_job runs first, then build_job

C. build_job runs first, then test_job

D. Only build_job runs

Solution

1. Step 1: Understand stages order

   Stages run in the order listed: first 'build', then 'test'.

2. Step 2: Match jobs to stages

   'build_job' is in 'build' stage, so it runs before 'test_job' in 'test' stage.

3. Final Answer:

   build_job runs first, then test_job -> Option C

4. Quick Check:

   Stages run in order listed [OK]

Hint: Jobs run by stage order top to bottom [OK]

Common Mistakes:

• Assuming jobs run in alphabetical order
• Thinking jobs run in parallel by default
• Ignoring the stages list order

4. You wrote this job in .gitlab-ci.yml but it never runs:

deploy_job:
  script:
    - echo "Deploying"
  only:
    - main

What is the likely reason?

medium

A. The job is missing a stage definition

B. The branch name is incorrect; it should be 'master' instead of 'main'

C. The 'only' keyword is deprecated; use 'rules' instead

D. The script command is invalid

Solution

1. Step 1: Check the stage assignment

   The job does not specify a 'stage' key, so it defaults to the 'test' stage.

2. Step 2: Impact of missing stage in global stages

   If the root-level 'stages' does not include 'test', GitLab fails the job because the stage is undefined in the global stages list.

3. Final Answer:

   The job is missing a stage definition -> Option A

4. Quick Check:

   Default stage 'test' must be in 'stages' list [OK]

Hint: Default stage is 'test'; must be defined in 'stages' if used [OK]

Common Mistakes:

• Assuming branch name is wrong without checking
• Forgetting to define a stage (defaults to 'test' if missing)
• Thinking script command syntax is wrong

5. You want a job to run only on the develop branch and after the build stage completes successfully. Which .gitlab-ci.yml snippet correctly achieves this?

hard

A. deploy_job:
stage: deploy
script:
- echo "Deploying"
rules:
- if: '$CI_COMMIT_BRANCH == "develop"'
when: on_success
needs:
- build_job

B. deploy_job:
stage: deploy
script:
- echo "Deploying"
only:
- develop
after_script:
- build_job

C. deploy_job:
stage: deploy
script:
- echo "Deploying"
rules:
- branch: develop
when: always
dependencies:
- build_job

D. deploy_job:
stage: deploy
script:
- echo "Deploying"
except:
- main
needs:
- build

Solution

1. Step 1: Use 'rules' to run job only on 'develop' branch

   The 'rules' keyword with condition '$CI_COMMIT_BRANCH == "develop"' ensures the job runs only on that branch.

2. Step 2: Use 'needs' to wait for 'build_job'

   The 'needs' keyword makes this job wait for 'build_job' to finish successfully before running.

3. Final Answer:

   deploy_job: stage: deploy script: - echo "Deploying" rules: - if: '$CI_COMMIT_BRANCH == "develop"' when: on_success needs: - build_job -> Option A

4. Quick Check:

   'rules' + 'needs' control branch and stage order [OK]

Hint: Use 'rules' for branch and 'needs' for stage dependency [OK]

Common Mistakes:

• Using deprecated 'only' or 'except' keywords
• Confusing 'after_script' with job dependencies
• Incorrect 'needs' or 'dependencies' usage