Learn GitLab CI/CD - Pre-Requisites Skills & Setup Environment

#Introduction

Welcome to the Learn GitLab CI/CD series! GitLab CI/CD is a CI/CD system built directly into the GitLab platform — from repository and issue tracking to pipelines that run automatically on every push. Mastering it is one of the fastest paths toward a DevOps Engineer, Cloud Engineer, or even Release Engineer role. But before writing your first .gitlab-ci.yml, there are three foundations you must hold on to: Git & GitLab workflow basics, the YAML format, and shell scripting basics. Without all three, you'll get lost in the upcoming episodes — because a pipeline is ultimately just a YAML file that triggers shell commands inside a Git repository.

Episode 0 is the foundation layer. We'll dig into those three skills, then set up a complete working environment: a GitLab.com account (or self-hosted GitLab), an authenticated GitLab CLI (glab), and VS Code with the GitLab Workflow extension for auto-complete, linting, and pipeline status. By the end of this episode, you'll have a machine ready to write and run your first GitLab CI/CD pipeline.

#Main Discussion

#Foundation Skill 1: Git & GitLab Workflow

GitLab CI/CD pipelines are automatically triggered by events that happen in the repository — from commits pushed to a branch, to merge requests being opened, to tags being released. That's why understanding Git and GitLab is no longer a choice, but an absolute prerequisite.

git init
git add .
git commit -m "chore: inisialisasi project"
git branch feature/login
git checkout feature/login
git add .
git commit -m "feat: halaman login"
git push origin feature/login

The most important mental model: a commit is a checkpoint you can return to at any time, and a branch is a way to develop features without breaking the main line. In GitLab, the collaboration mechanism is called a Merge Request (MR) — the equivalent of a Pull Request in GitHub. MRs are the heart of collaboration in GitLab, and later on many pipelines will be designed specifically to run every time an MR is opened or updated. If you're not yet comfortable with git add, git commit, and git push, take some time to read the learn-git series on this blog first.

#Foundation Skill 2: The YAML Format

GitLab CI/CD describes an entire pipeline as a YAML file (YAML Ain't Markup Language) placed at the repository root. Every syntax element — from stages and jobs to scripts — is written in YAML. Its three fundamental concepts:

• Key-value: a name and value pair, written as nama: nilai.
• List: a series of items indented with - in front of each item.
• Nesting: hierarchy is created solely from indentation — this is what causes errors most often.

name: my-app
version: 1.0.0
stack:
  - web
  - api
config:
  debug: true
  port: 8080
  jobs:
    - name: build
      run: npm ci

Note that hierarchy is determined by the number of spaces in front of a line, not by brackets or semicolons. Understand this pattern well, because every pipeline you write will depend on correct indentation depth.

#Foundation Skill 3: Shell Scripting Basics

Every job in GitLab CI/CD ultimately executes commands inside a shell — bash by default. A job is considered failed if a command it runs returns an exit code other than 0, and the pipeline stops. The most basic pattern looks like this:

#!/bin/bash
set -e
APP_DIR="./src"
echo "Memeriksa direktori $APP_DIR"
if [ -d "$APP_DIR" ]; then
  echo "Direktori ditemukan"
else
  echo "Direktori tidak ada" >&2
  exit 1
fi

Three things you must understand from the example above: variables (assigned without $, used with $), branching with if for flow control, and exit codes as the success-failure language of a command. The learn-bash-scripting series on this blog is a highly recommended companion.

#Setup 1: GitLab Account

The first step is trivial but often forgotten: make sure you have a GitLab account. There are two main options:

• GitLab.com (SaaS) — the official service managed by GitLab. It's the fastest way to learn because it's free and provides shared runners ready to run pipelines without any server setup.
• Self-hosted GitLab — install your own GitLab instance (free CE edition or paid EE) on your servers. Popular at companies that need full control over their data and infrastructure.

Simply register at gitlab.com, verify your email, then create a new project from the New project button. That project is the home of your repository and the place where pipelines will be executed.

#Setup 2: Installing the GitLab CLI (glab)

glab is GitLab's official command-line tool that lets you manage projects, merge requests, issues, and even pipelines directly from the terminal without opening a browser.

brew install glab
sudo apt install glab
winget install glab.glab
glab version

The commands above are for macOS (Homebrew), Ubuntu/Debian (package in universe), and Windows (winget) respectively. Once installed, the next step is authentication:

glab auth login
glab auth status

The glab auth login command presents a series of interactive prompts: choose your host (GitLab.com or a self-managed instance), choose your authentication method (browser OAuth is most convenient, or a Personal Access Token), then follow the flow. The token is stored in ~/.config/glab-cli/config.yml. Verify the result:

$ glab version
glab version 1.63.0 (2026-06-12)
 
$ glab auth status
gitlab.com
  ✓ Logged in to gitlab.com as arman-dp
  ✓ Auth method: oauth
  ✓ Git operations for gitlab.com configured to use https

If you see the ✓ Logged in marker, your CLI environment is connected to GitLab. glab commands you'll use frequently:

#Setup 3: VS Code with the GitLab Workflow Extension

To write .gitlab-ci.yml comfortably, install Visual Studio Code and the GitLab Workflow extension (official, from GitLab). This extension provides:

• Syntax highlighting specifically for .gitlab-ci.yml.
• Auto-complete for keywords like stages, script, and rules.
• Linter that validates pipeline syntax in real time — indentation errors are visible before the file is even pushed.
• Pipeline status shown directly in the editor for the branch being processed.

To install it: open VS Code, press Ctrl+Shift+X to open the Extensions panel, search for "GitLab Workflow", click Install, then authenticate from the command palette (Cmd+Shift+P → GitLab: Authenticate). Any file named .gitlab-ci.yml in the project root will be automatically detected and linted.

#Common Setup Mistakes

1. Not logged in to glab. Any command like glab repo list will show a message prompting you to run glab auth login first. The solution is to run glab auth login.
2. The YAML file uses tabs. The YAML parser will reject the file. Configure VS Code to insert spaces (not tabs) when you press the Tab key.
3. The project has no CI/CD enabled. Pipelines only run if a .gitlab-ci.yml file exists at the repository root. Also make sure the CI/CD setting in the project isn't disabled.

#Closing

In this episode 0, you've set up a complete foundation for learning GitLab CI/CD:

• Three prerequisite skills: Git & GitLab workflow basics (commit, branch, Merge Request), the YAML format (key-value, list, nesting), and bash basics (set -e, variables, exit codes).
• A GitLab.com account or self-hosted GitLab as the home of your repository and pipelines.
• An authenticated GitLab CLI (glab), complete with glab version and glab auth status.
• VS Code with the GitLab Workflow extension for auto-complete, linting, and pipeline status.

Your environment is now ready. In episode 1 we'll pause the typing for a moment to understand the history, concepts, and core architecture of GitLab CI/CD — why this all-in-one platform dominates the enterprise, how the GitLab Server, Runner, and .gitlab-ci.yml work together, and an honest comparison with GitHub Actions and Jenkins. See you in episode 1!