Bird
Raised Fist0
Gitdevops~10 mins

GitLab CI basics - Interactive Code Practice

Choose your learning style10 modes available
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to define a basic GitLab CI job named test_job.

Git
test_job:
  stage: test
  script:
    - [1]
Drag options to blanks, or click blank then click option'
Aecho "Running tests"
Brun tests
Cexecute tests
Dstart test
Attempts:
3 left
💡 Hint
Common Mistakes
Using phrases that are not shell commands.
Forgetting to use quotes around text.
2fill in blank
medium

Complete the code to specify the build stage in the GitLab CI configuration.

Git
stages:
  - [1]
  - test
  - deploy
Drag options to blanks, or click blank then click option'
Abuild
Bdeploy
Crelease
Dcompile
Attempts:
3 left
💡 Hint
Common Mistakes
Using non-standard stage names.
Mixing up the order of stages.
3fill in blank
hard

Fix the error in the job definition by completing the missing keyword for the job name.

Git
[1]:
  stage: build
  script:
    - echo "Building project"
Drag options to blanks, or click blank then click option'
Abuild_job
Bbuild
Cstage
Djob
Attempts:
3 left
💡 Hint
Common Mistakes
Using reserved keywords like job or stage as job names.
Adding spaces or invalid characters.
4fill in blank
hard

Fill both blanks to create a job that runs only on the main branch and uses the deploy stage.

Git
deploy_job:
  stage: [1]
  script:
    - echo "Deploying application"
  only:
    - [2]
Drag options to blanks, or click blank then click option'
Adeploy
Bmain
Ctest
Dfeature
Attempts:
3 left
💡 Hint
Common Mistakes
Using the wrong stage name.
Specifying a branch name that does not exist.
5fill in blank
hard

Fill all three blanks to define a job named lint that runs in the test stage, executes npm run lint, and runs only on merge requests.

Git
lint:
  stage: [1]
  script:
    - [2]
  only:
    - [3]
Drag options to blanks, or click blank then click option'
Atest
Bnpm run lint
Cmerge_requests
Ddeploy
Attempts:
3 left
💡 Hint
Common Mistakes
Using the wrong stage name.
Writing the script command incorrectly.
Specifying the wrong condition in only.

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard