GitLab CI basics - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

What is the output of this GitLab CI pipeline status command?

You run the command gitlab-runner status on a machine where GitLab Runner is installed and registered. What output do you expect if the runner is active and connected?

Git

gitlab-runner status

A GitLab Runner: paused

B

Runtime platform: linux/amd64

GitLab Runner: stopped

C Error: command not found

D

Runtime platform: linux/amd64

GitLab Runner: running

💡 Hint

Think about what the status command shows when the runner is working.

The gitlab-runner status command shows the runner's platform and whether it is running or stopped. If active, it says 'GitLab Runner: running'.

❓ Configuration

intermediate

Which .gitlab-ci.yml snippet correctly defines a job that runs only on the master branch?

You want a job named deploy to run only when commits are pushed to the master branch. Which snippet achieves this?

A

deploy:
  script:
    - echo Deploying...
  only:
    - master

B

deploy:
  script:
    - echo Deploying...
  rules:
    - if: '$CI_COMMIT_BRANCH == "develop"'

C

deploy:
  script:
    - echo Deploying...
  except:
    - master

D

deploy:
  script:
    - echo Deploying...
  when: manual

💡 Hint

Look for the keyword that specifies branches to include.

The only keyword restricts the job to run only on specified branches. Here, only: - master means the job runs only on the master branch.

🔀 Workflow

advanced

What is the correct order of stages in this GitLab CI pipeline configuration?

Given this snippet, what is the order in which jobs run?

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script: echo Building

test_job:
  stage: test
  script: echo Testing

deploy_job:
  stage: deploy
  script: echo Deploying

A 1,2,3

B 3,2,1

C 2,1,3

D 1,3,2

💡 Hint

Jobs run in the order of stages defined at the top.

Stages define the order: build first, then test, then deploy. Jobs in the same stage run in parallel.

❓ Troubleshoot

advanced

Why does this GitLab CI job fail with 'script not found' error?

This job fails with an error saying the script is not found:

job1:
  script:
    - ./deploy.sh

The deploy.sh file exists in the repository root. What is the most likely cause?

A The <code>script</code> keyword is misspelled in the YAML file.

B GitLab CI does not support running shell scripts.

C The <code>deploy.sh</code> file is not executable or missing execute permission.

D The job name <code>job1</code> is invalid.

💡 Hint

Check file permissions for scripts in CI jobs.

If the script file lacks execute permission, the runner cannot run it, causing a 'script not found' error.

✅ Best Practice

expert

Which GitLab CI configuration snippet correctly caches dependencies to speed up pipeline runs?

You want to cache the node_modules folder between pipeline runs to avoid reinstalling packages every time. Which snippet correctly configures caching?

A

cache:
  paths:
    - node_modules/

B

cache:
  key: "node_modules"
  paths:
    - node_modules/

C

cache:
  paths:
    - node_modules
  when: always

D

cache:
  paths:
    - node_modules
  policy: push

💡 Hint

Caching often requires a key to identify cache versions.

Defining a cache key ensures the cache is stored and restored properly. Without a key, caching may not work as expected.

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