Ravindra BagaleCourses & study guides मराठी Track your progress

Guides

GitLab CI Pipeline for Beginners (.gitlab-ci.yml)

Write stages and jobs in .gitlab-ci.yml, run on a Runner, keep artifacts, and read the job log when red.

Friends, stages are the timetable, jobs are the workers. Chala mitrano — make test go green before build ships anything.

Quick answer

Hold this vertical picture:

  1. Add stages test and build.
  2. Write job scripts.
  3. Add artifacts.
  4. Tag the runner.
  5. Push and open the pipeline.

Language: English · मराठी · हिंदी

Push / MRPipeline created test stageJobs run build stageArtifacts saved RunnerExecutes scripts Green checkMerge ready
GitLab CI flow

Why .gitlab-ci.yml

One file tells GitLab how to test and build every push.

Why: Manual builds drift per laptop. What: YAML stages and jobs on a Runner. How: Commit the file at the repo root.

Example 1: Minimal .gitlab-ci.yml

Type this:

mkdir -p /tmp/glab && printf '%s\n' 'stages:' '  - test' '  - build' 'test_job:' '  stage: test' '  script:' '    - echo hello-test' 'build_job:' '  stage: build' '  script:' '    - echo hello-build' > /tmp/glab/.gitlab-ci.yml && cat /tmp/glab/.gitlab-ci.yml

You will see:

stages:

What it means: Stages run in order; jobs in a stage can run in parallel.

Example 2: Validate YAML shape

Type this:

python3 -c "import pathlib; t=pathlib.Path('/tmp/glab/.gitlab-ci.yml').read_text(); print('ok' if 'stages:' in t and 'script:' in t else 'bad')"

You will see:

ok

What it means: Broken indentation is the number-one beginner failure.

Example 12: List stages mentally

Type this:

printf '%s\n' 'test then build then deploy — never deploy before test'

You will see:

test then build then deploy — never deploy before test

What it means: Order in stages: is the safety rail.

Concept 1: Artifacts and cache

Artifacts move outputs; cache speeds installs.

Why: Without artifacts later jobs cannot see dist/. What: paths under artifacts:. How: build job saves dist/.

Example 3: Add an artifact

Type this:

printf '%s\n' 'build_job:' '  stage: build' '  script:' '    - mkdir -p dist && echo app > dist/app.txt' '  artifacts:' '    paths:' '      - dist/' > /tmp/glab/arti.yml && grep -A2 artifacts /tmp/glab/arti.yml

You will see:

artifacts:

What it means: Artifacts pass files to later jobs or downloaders.

Example 5: Cache node_modules pattern

Type this:

printf '%s\n' 'cache:' '  key: npm' '  paths:' '    - node_modules/' > /tmp/glab/cache.yml && cat /tmp/glab/cache.yml

You will see:

cache:

What it means: Cache speeds installs; artifacts ship outputs.

Example 8: Include a template file

Type this:

printf '%s\n' 'include:' '  - local: /ci/templates.yml' > /tmp/glab/include.yml && cat /tmp/glab/include.yml

You will see:

include:

What it means: Shared templates keep many repos consistent at Capgemini.

Concept 2: Tags and rules

Pick runners; limit deploy to main.

Why: Wrong tag leaves jobs pending forever. What: tags: and rules:. How: Match runner tags; gate on branch.

Example 4: Runner tag idea

Type this:

printf '%s\n' 'test_job:' '  stage: test' '  tags:' '    - docker' '  script:' '    - echo on-docker-runner' > /tmp/glab/tags.yml && grep -A3 tags /tmp/glab/tags.yml

You will see:

tags:

What it means: Tags pick which GitLab Runner executes the job.

Example 6: only/rules sketch

Type this:

printf '%s\n' 'deploy:' '  stage: build' '  script: ["echo deploy"]' '  rules:' '    - if: \$CI_COMMIT_BRANCH == "main"' > /tmp/glab/rules.yml && cat /tmp/glab/rules.yml

You will see:

rules:

What it means: Run deploy only on main — Infosys teams expect branch rules.

Example 9: Variables block

Type this:

printf '%s\n' 'variables:' '  NODE_ENV: "test"' '  APP_NAME: "payments"' > /tmp/glab/vars.yml && cat /tmp/glab/vars.yml

You will see:

variables:

What it means: CI variables override without editing every script line.

Concept 3: Logs and failures

Non-zero exit fails the job.

Why: Guessing without the log wastes hours. What: Open job log; fix script. How: before_script + clear echo lines.

Example 7: Job log simulation

Type this:

printf '%s\n' 'hello-test' 'hello-build' > /tmp/glab/fake-log.txt && cat /tmp/glab/fake-log.txt

You will see:

hello-test
hello-build

What it means: Green jobs print script lines; red jobs stop at the failing line.

Example 10: before_script

Type this:

printf '%s\n' 'default:' '  before_script:' '    - echo prepare' > /tmp/glab/before.yml && cat /tmp/glab/before.yml

You will see:

before_script:

What it means: Shared setup for every job under default.

Example 11: Exit code fails the job

Type this:

bash -c 'false; echo exit=$?' | tail -1

You will see:

exit=1

What it means: Any non-zero script line fails the GitLab job.

GitLab CI card

1 stages 2 jobs with script 3 artifacts 4 tags/rules 5 read the job log

Suppose: yaml invalid

Fix indentation; stages must be a list.

Suppose: stuck pending

No Runner matches the job tags.

Ravindra Bagale's Tip

At Infosys, a first GitLab merge request is often just test + build with artifacts. Reviewers open the job log.

Check yourself (quiz)

Q1. File name?

.gitlab-ci.yml at repo root

Q2. Stage order?

As listed under stages

Q3. Artifacts?

Pass files between jobs

Q4. Pending forever?

No matching Runner tag

Q5. Red job?

Non-zero script exit

Q6. rules?

When the job should run

Reading tracking

Mark this guide when you finish. Your browser remembers it on this device.

stages → jobs → artifacts → runner → green. Did you understand? Let us try it once more.

Frequently asked questions

Where does the file live?

Repository root as .gitlab-ci.yml.

Stage vs job?

Stage is the phase; job is the work unit.

Artifacts vs cache?

Artifacts ship outputs; cache speeds repeats.

Why pending?

No Runner with matching tags.

How does a job go red?

Any script line exits non-zero.

Shared YAML?

include: local or project templates.