Maven / GitLab CI Basics Interview Questions

# Minimal .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Compiling the code..."
    - echo "Compile complete."

test-job:
  stage: test
  script:
    - echo "Running tests..."

deploy-job:
  stage: deploy
  script:
    - echo "Deploying to production..."

# A pipeline with 3 stages:
# Stage 1 (build): runs first
# Stage 2 (test): runs after build passes
# Stage 3 (deploy): runs after test passes

stages:
  - build
  - test
  - deploy

build-app:
  stage: build
  script: make build

unit-tests:
  stage: test
  script: make test

deploy-staging:
  stage: deploy
  script: make deploy

# Define stages at the top level of .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

# Jobs reference their stage with the "stage" keyword
build-job:
  stage: build
  script:
    - echo "Building..."

test-unit:
  stage: test
  script:
    - echo "Running unit tests..."

test-integration:
  stage: test       # also in "test" stage - runs PARALLEL to test-unit
  script:
    - echo "Running integration tests..."

deploy-job:
  stage: deploy
  script:
    - echo "Deploying..."

# Minimum viable job (only "script" is required):
hello-world:
  script:
    - echo "Hello, World!"

# Full job with common keywords:
build-app:
  stage: build
  image: node:20-alpine
  before_script:
    - npm ci
  script:
    - npm run build
  after_script:
    - echo "Build complete"
  artifacts:
    paths:
      - dist/
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

# Global before_script runs before every job's script
default:
  before_script:
    - echo "Global setup"

build-job:
  stage: build
  before_script:
    - echo "Job-specific setup (overrides global)"  # overrides the default
  script:
    - npm ci
    - npm run build
  after_script:
    - echo "Cleanup - always runs even if script fails"

# Set a default image for all jobs
default:
  image: ubuntu:24.04

# Override image for a specific job
build-node:
  stage: build
  image: node:20-alpine     # uses Node.js 20
  script:
    - node --version
    - npm ci
    - npm run build

build-python:
  stage: build
  image: python:3.12-slim   # different image for Python job
  script:
    - pip install -r requirements.txt
    - python -m pytest

# Image with a registry prefix
deploy-job:
  image: registry.gitlab.com/myorg/myimage:latest
  script:
    - ./deploy.sh

# Image with a specific SHA (for reproducibility)
test-job:
  image:
    name: node:20-alpine
    entrypoint: [""]   # override the entrypoint if needed
  script:
    - npm test

build-job:
  stage: build
  script:
    - npm ci
    - npm run build           # creates dist/ directory
  artifacts:
    paths:
      - dist/                 # save entire dist directory
      - coverage/report.html  # save a specific file
    exclude:
      - dist/**/*.map         # exclude sourcemap files
    expire_in: 1 week        # auto-delete after 1 week (default: 30 days)
    when: always             # save artifacts even if job fails

test-job:
  stage: test
  script:
    - ls dist/               # artifacts from build-job are available here!
    - npm test
  dependencies:
    - build-job              # explicitly specify which artifacts to download

# JUnit test reports (display inline in MR UI)
test-with-report:
  stage: test
  script:
    - pytest --junitxml=report.xml
  artifacts:
    reports:
      junit: report.xml

# Cache example: reuse npm packages across pipeline runs
cache:
  key: "$CI_COMMIT_REF_SLUG"   # different cache per branch
  paths:
    - node_modules/
  policy: pull-push           # default: download at start, upload at end

# Artifacts example: pass build output to next stage
build:
  script: npm run build
  artifacts:
    paths:
      - dist/

# Best practice: use both together
build-job:
  cache:
    paths:
      - node_modules/  # cache deps for speed
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/          # pass output to deploy stage

# Defining variables in .gitlab-ci.yml
variables:
  DATABASE_URL: "postgres://localhost/mydb"  # available to all jobs
  DEPLOY_ENV: "staging"

build-job:
  variables:
    NODE_ENV: "production"   # job-level variable (overrides global)
  script:
    - echo "Branch: $CI_COMMIT_BRANCH"
    - echo "Commit: $CI_COMMIT_SHA"
    - echo "DB: $DATABASE_URL"
    - echo "Node env: $NODE_ENV"

deploy:
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
    - echo "Deployed by $GITLAB_USER_LOGIN from $CI_COMMIT_BRANCH"

deploy-prod:
  stage: deploy
  script:
    - ./deploy.sh production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"     # only run on main branch
      when: on_success                     # (default) run if prior stages passed
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: on_success
    - when: never                          # never run for any other condition

# Common rules patterns:
job-on-mr:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

job-on-tag:
  rules:
    - if: $CI_COMMIT_TAG                   # runs when a git tag is pushed

job-manual-on-prod:
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual                         # must be manually triggered in UI

job-with-changes:
  rules:
    - changes:                             # only run if these files changed
        - src/**/*
        - package.json

job-allow-fail:
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      allow_failure: true                  # pipeline passes even if this fails

# Legacy only/except (works but not recommended for new pipelines):
deploy-old:
  script: ./deploy.sh
  only:
    - main
    - tags
  except:
    - schedules

# Modern rules equivalent (preferred):
deploy-new:
  script: ./deploy.sh
  rules:
    - if: $CI_COMMIT_TAG                         # matches any tag push
    - if: $CI_COMMIT_BRANCH == "main"
      when: on_success
    - when: never

stages:
  - build
  - test
  - deploy

build-frontend:
  stage: build
  script: npm run build
  artifacts:
    paths: [dist/]

build-backend:
  stage: build
  script: go build -o api ./cmd
  artifacts:
    paths: [api]

# Without needs: test-frontend must wait for BOTH build jobs to finish
# With needs: test-frontend starts as soon as build-frontend is done
test-frontend:
  stage: test
  needs:
    - build-frontend      # only waits for this specific job
  script: npm test

test-backend:
  stage: test
  needs:
    - build-backend       # only waits for this specific job
  script: go test ./...

deploy:
  stage: deploy
  needs:
    - test-frontend
    - test-backend
  script: ./deploy.sh

# Only create pipelines for main branch, MRs, and tags
workflow:
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_TAG
    - when: never   # suppress all other pipeline triggers

# Name the pipeline dynamically
workflow:
  name: "Pipeline for $CI_COMMIT_REF_NAME"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      name: "MR Pipeline: $CI_MERGE_REQUEST_TITLE"
    - if: $CI_COMMIT_BRANCH

# Prevent duplicate pipelines (MR + branch pipelines)
# This is a very common pattern:
workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
      when: never   # skip branch pipeline when MR pipeline exists
    - if: $CI_COMMIT_BRANCH

# Define a hidden job template (starts with .)
.base-deploy:
  image: alpine:latest
  before_script:
    - apk add --no-cache curl
    - echo "Logging into registry..."
  after_script:
    - echo "Deployment complete"
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

# Jobs extend the template
deploy-staging:
  extends: .base-deploy
  script:
    - ./deploy.sh staging
  environment:
    name: staging

deploy-production:
  extends: .base-deploy
  script:
    - ./deploy.sh production
  environment:
    name: production
  rules:                          # overrides the template rules
    - if: $CI_COMMIT_TAG
      when: manual

# extends with multiple parents (array form)
.logging:
  after_script:
    - send-logs.sh

my-job:
  extends:
    - .base-deploy
    - .logging          # merges config from both (later parent wins on conflict)

# Include multiple sources
include:
  - local: '/ci/build.yml'         # file in same repo
  - project: 'myorg/ci-templates' # file from another project
    ref: main
    file: '/templates/deploy.yml'
  - template: 'SAST.gitlab-ci.yml'  # GitLab built-in security template
  - remote: 'https://cdn.example.com/ci/lint.yml'  # external URL

# Using included configuration
# The included files can define jobs, stages, variables, etc.
# They are merged into the main .gitlab-ci.yml

stages:
  - build
  - test
  - security
  - deploy

# Your local jobs here, plus everything from the included files

# Basic environment definition
deploy-staging:
  stage: deploy
  script:
    - ./deploy.sh staging
  environment:
    name: staging
    url: https://staging.example.com
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

deploy-production:
  stage: deploy
  script:
    - ./deploy.sh production
  environment:
    name: production
    url: https://example.com
  rules:
    - if: $CI_COMMIT_TAG
      when: manual              # requires manual approval

# Dynamic review environments per merge request
review-app:
  stage: deploy
  script:
    - deploy-to-review.sh $CI_COMMIT_REF_SLUG
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_COMMIT_REF_SLUG.review.example.com
    on_stop: stop-review
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

stop-review:
  stage: deploy
  script:
    - teardown-review.sh $CI_COMMIT_REF_SLUG
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: manual

# Method 1: using rules
deploy-production:
  stage: deploy
  script:
    - ./deploy.sh production
  environment: production
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual              # must be clicked to run
      allow_failure: false      # blocks pipeline completion until clicked

# Method 2: legacy "when" keyword
deploy-prod-legacy:
  stage: deploy
  script: ./deploy.sh production
  when: manual
  only:
    - main

# Blocking vs non-blocking manual jobs:
# Non-blocking (default): pipeline is marked as passed without clicking
# Blocking: pipeline stays in "blocked" status until job is triggered

# To make it blocking (requires allow_failure: false):
critical-approval:
  stage: approve
  script: echo "Approval recorded"
  when: manual
  allow_failure: false          # blocks the pipeline

# Protected manual jobs (only certain roles can trigger):
# Set in project Settings > CI/CD > Protected environments

# allow_failure: true - job failure does not fail the pipeline
linting:
  stage: test
  script:
    - eslint src/ --max-warnings 0
  allow_failure: true          # linting warnings won't block deployment

# allow_failure with rules (preferred modern approach)
code-quality:
  stage: test
  script:
    - run-quality-check.sh
  rules:
    - if: $CI_COMMIT_BRANCH
      allow_failure: true
    - if: $CI_COMMIT_TAG
      allow_failure: false     # strict on releases

# allow_failure with exit codes
# Only allow specific non-zero exit codes:
flaky-test:
  script:
    - run-flaky-tests.sh
  allow_failure:
    exit_codes: 137            # allow OOM kills (exit code 137)

# allow_failure: true with manual jobs
# makes the manual job non-blocking
optional-deploy:
  when: manual
  allow_failure: true          # pipeline passes without triggering this job

# Run the same job N times in parallel
test:
  stage: test
  image: ruby:3.2
  script:
    - bundle exec rspec
  parallel: 5
  # GitLab creates 5 jobs: test 1/5, test 2/5, ..., test 5/5
  # Each job gets: CI_NODE_INDEX (1-5) and CI_NODE_TOTAL (5)
  # Your test framework uses these to split the test suite

# Parallel matrix - run job with different variable combinations
build:
  stage: build
  script:
    - echo "Node: $NODE_VERSION on $OS"
  parallel:
    matrix:
      - NODE_VERSION: ["18", "20", "22"]
        OS: ["ubuntu", "alpine"]
  # Creates 6 jobs: all combinations of NODE_VERSION x OS

# Access which shard you are in:
test-shard:
  script:
    - echo "Running shard $CI_NODE_INDEX of $CI_NODE_TOTAL"
    - run-tests --split $CI_NODE_TOTAL --shard $CI_NODE_INDEX

# In .gitlab-ci.yml - detect schedule trigger:
nightly-test:
  stage: test
  script:
    - run-full-test-suite.sh
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"   # only runs when scheduled

regular-test:
  stage: test
  script:
    - run-quick-tests.sh
  rules:
    - if: $CI_PIPELINE_SOURCE != "schedule"   # skip during scheduled runs

# Variables defined in the schedule are available as CI/CD variables:
nightly-deploy:
  script:
    - echo "Running type: $PIPELINE_TYPE"     # set in schedule config
    - echo "Env: $DEPLOY_ENV"

# Trigger a pipeline via API:
curl --request POST \
  --form "token=<trigger-token>" \
  --form "ref=main" \
  --form "variables[DEPLOY_ENV]=staging" \
  "https://gitlab.example.com/api/v4/projects/123/trigger/pipeline"

# Trigger a downstream pipeline from a job (bridge job):
trigger-deploy:
  stage: deploy
  trigger:
    project: myorg/deploy-repo
    branch: main
    strategy: depend   # wait for downstream pipeline to complete

# Check trigger source in rules:
job-for-mr-only:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

# Simple retry: retry up to 2 times on any failure
flaky-test:
  script:
    - run-tests.sh
  retry: 2                     # total: 3 attempts (1 original + 2 retries)

# Retry only on specific failure types:
network-test:
  script:
    - curl https://api.example.com/data
  retry:
    max: 2
    when:
      - runner_system_failure   # runner itself crashed
      - stuck_or_timeout_failure  # job timed out
      - api_failure             # GitLab API error during job
      # NOT for script failures (that would mask real test failures)

# All retry "when" values:
# always, unknown_failure, script_failure, api_failure,
# runner_system_failure, missing_dependency_failure,
# stuck_or_timeout_failure, scheduler_failure, data_integrity_failure

# Job-level timeout
long-running-test:
  script:
    - run-full-integration-tests.sh
  timeout: 2 hours             # stop after 2 hours

build-job:
  script:
    - make build
  timeout: 30 minutes          # stop after 30 minutes

# Timeout format examples:
# timeout: 3600         (seconds)
# timeout: 60 minutes
# timeout: 2 hours
# timeout: 1h 30m
# timeout: 1 day

# Default timeout hierarchy:
# 1. Job-level timeout (if set)
# 2. Project-level timeout (Settings > CI/CD > General pipelines)
# 3. Runner timeout (set when runner is registered)
# The smallest of project timeout and runner timeout applies,
# then job-level timeout can only be lower than that

# Build and push to the GitLab Container Registry:
build-image:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA .
    - docker build -t $CI_REGISTRY_IMAGE:latest .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
    - docker push $CI_REGISTRY_IMAGE:latest

# Pull from registry in a later job:
deploy-job:
  stage: deploy
  script:
    - docker pull $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA
    - docker run -d $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

# Run tests with a PostgreSQL database service:
test-with-db:
  stage: test
  image: python:3.12
  services:
    - postgres:16-alpine          # starts a Postgres container
  variables:
    POSTGRES_DB: testdb
    POSTGRES_USER: postgres
    POSTGRES_PASSWORD: secret
    DATABASE_URL: "postgresql://postgres:secret@postgres/testdb"
  script:
    - pip install -r requirements.txt
    - python -m pytest

# Multiple services:
integration-test:
  image: node:20
  services:
    - redis:7-alpine
    - postgres:16-alpine
    - name: rabbitmq:3-management
      alias: rabbit             # access as "rabbit" hostname
  script:
    - npm test

# Service with alias and entrypoint override:
custom-service:
  services:
    - name: my-registry/my-service:latest
      alias: api-mock
      entrypoint: ["/usr/bin/api-mock"]
      command: ["--port", "8080"]

# Set defaults for all jobs
default:
  image: ubuntu:24.04
  before_script:
    - apt-get update -qq
    - echo "Setting up environment..."
  after_script:
    - echo "Job complete"
  retry:
    max: 1
    when: runner_system_failure
  timeout: 1 hour
  interruptible: true           # allow newer pipelines to cancel this job

# Jobs inherit defaults but can override individual settings:
build-job:
  image: node:20-alpine         # overrides the default ubuntu image
  script:
    - npm ci && npm run build   # before_script from default still runs

python-test:
  # uses all defaults: ubuntu image, before_script, retry, timeout
  script:
    - pip install -r requirements.txt
    - pytest
  before_script:
    - pip install --upgrade pip # overrides global before_script entirely

# Define a reusable block with an anchor
.common_rules: &common_rules
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

.common_setup: &common_setup
  image: node:20-alpine
  before_script:
    - npm ci

# Reuse with alias (*) or merge key (<<: *)
build-job:
  <<: *common_setup        # merge the anchor content
  <<: *common_rules        # YAML 1.1 syntax
  script:
    - npm run build

test-job:
  <<: *common_setup
  <<: *common_rules
  script:
    - npm test

# Anchors for variables
.env_vars: &prod_vars
  variables:
    ENVIRONMENT: production
    LOG_LEVEL: error

deploy-prod:
  <<: *prod_vars
  script: ./deploy.sh production

# Jobs that run only in MR pipelines:
code-review:
  script:
    - run-code-quality.sh
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

# Useful MR-specific variables:
check-mr:
  script:
    - echo "MR ID: $CI_MERGE_REQUEST_ID"
    - echo "Target branch: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME"
    - echo "Source branch: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME"
    - echo "MR title: $CI_MERGE_REQUEST_TITLE"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

# Merged results pipeline (tests the post-merge state):
# Enable in Settings > Merge requests > Merged results pipelines
# Runs on the merge commit that would result from accepting the MR

# Basic cache with branch-scoped key:
cache:
  key: "$CI_COMMIT_REF_SLUG"     # different cache per branch
  paths:
    - .npm/
    - node_modules/

# Cache keyed to dependency file (invalidates when file changes):
cache:
  key:
    files:
      - package-lock.json         # cache key changes when lockfile changes
    prefix: "$CI_COMMIT_REF_SLUG"
  paths:
    - node_modules/

# Cache policies (pull-push is default):
job-with-readonly-cache:
  cache:
    key: $CI_COMMIT_REF_SLUG
    paths:
      - node_modules/
    policy: pull                  # only download cache, never update it

job-that-updates-cache:
  cache:
    policy: push                  # only upload, skip downloading

# Per-job cache:
build:
  cache:
    key: "build-$CI_COMMIT_REF_SLUG"
    paths: [dist/]

test:
  cache:
    key: "deps-$CI_COMMIT_REF_SLUG"
    paths: [node_modules/]

# Method 1: GitLab UI
# Navigate to: Build > Pipelines > then click "CI Lint"
# or: Project > CI/CD > Lint (path varies by GitLab version)
# Paste your YAML and click "Validate"

# Method 2: Pipeline Editor
# Navigate to: Build > Pipeline editor
# The editor validates in real-time as you type

# Method 3: GitLab API
curl --header "PRIVATE-TOKEN: <your-token>" \
     --header "Content-Type: application/json" \
     --data '{"content": "include:\n  - local: /.gitlab-ci.yml"}' \
     "https://gitlab.example.com/api/v4/projects/:id/ci/lint"

# Method 4: gitlab-ci-local (third-party tool)
# Run pipelines locally for development:
pip install gitlab-ci-local  # or: brew install gitlab-ci-local
gitlab-ci-local              # simulates pipeline execution locally

# The CI Lint tool checks:
# - Valid YAML syntax
# - Valid GitLab CI keywords
# - Correct job structure
# - Variable expansion
# - Stage references are defined

# Using a CI/CD component in .gitlab-ci.yml:
include:
  - component: $CI_SERVER_FQDN/myorg/my-components/deploy@1.0.0
    inputs:
      environment: production
      image_tag: $CI_COMMIT_SHORT_SHA

  # Use a specific version (tag), branch, or SHA:
  - component: gitlab.com/gitlab-org/ci-components/secret-detection@main

# Creating a component (in its own repository):
# File: templates/deploy.yml
---
spec:
  inputs:
    environment:
      description: "Deployment environment (staging or production)"
    image_tag:
      description: "Docker image tag to deploy"
      default: "latest"
---
deploy-$[[ inputs.environment ]]:
  stage: deploy
  script:
    - ./deploy.sh $[[ inputs.environment ]] $[[ inputs.image_tag ]]

# Parent pipeline (.gitlab-ci.yml):
stages:
  - generate
  - trigger

generate-child-config:
  stage: generate
  script:
    - generate-pipeline-config.sh > child-pipeline.yml  # dynamic YAML
  artifacts:
    paths:
      - child-pipeline.yml

trigger-child:
  stage: trigger
  trigger:
    include:
      - artifact: child-pipeline.yml
        job: generate-child-config
    strategy: depend              # wait for child to complete

# Or trigger from a static file:
trigger-static-child:
  trigger:
    include:
      - local: ci/child-pipeline.yml
    strategy: depend

# Child pipeline (ci/child-pipeline.yml):
stages:
  - build
  - test
build-child:
  stage: build
  script: echo "Child pipeline building..."

# Prevent concurrent deployments to production:
deploy-production:
  stage: deploy
  script:
    - ./deploy.sh production
  resource_group: production      # only one "production" deploy at a time
  environment: production

# Multiple environments, each serialized separately:
deploy-staging:
  script: ./deploy.sh staging
  resource_group: staging         # serializes staging deploys

deploy-production:
  script: ./deploy.sh production
  resource_group: production      # serializes production deploys separately

# Process mode (controls job ordering within the group):
deploy-job:
  resource_group: my-group
  process_mode: oldest_first      # FIFO - deploy in the order triggered
  # Options:
  # oldest_first (default): FIFO queue
  # newest_first: LIFO - skip old deploys, do most recent
  # unordered: no ordering guarantee

# Include GitLab security templates:
include:
  - template: Security/SAST.gitlab-ci.yml           # Static Application Security Testing
  - template: Security/Secret-Detection.gitlab-ci.yml  # Detect secrets/tokens in code
  - template: Security/Dependency-Scanning.gitlab-ci.yml
  - template: Security/DAST.gitlab-ci.yml            # Dynamic (requires running app)
  - template: Security/Container-Scanning.gitlab-ci.yml

stages:
  - build
  - test
  - security                  # security templates add jobs to appropriate stages
  - deploy

# These templates are maintained by GitLab and auto-update
# Results appear in:
# Secure > Vulnerability Report (GitLab Ultimate)
# As MR security widgets (GitLab Ultimate)

# SAST customisation:
variables:
  SAST_EXCLUDED_PATHS: "spec,test,tests,tmp"  # skip test directories
  SAST_EXCLUDED_ANALYZERS: "bandit"           # skip specific analyzer

# Secret Detection customisation:
  SECRET_DETECTION_EXCLUDED_PATHS: "tests/"

# Set globally for all jobs:
variables:
  GIT_STRATEGY: fetch          # default - fast incremental fetch

# Override for a specific job:
clean-build:
  variables:
    GIT_STRATEGY: clone        # ensure completely fresh checkout
  script:
    - make clean && make build

# Skip checkout for deploy-only jobs:
deploy-from-artifact:
  variables:
    GIT_STRATEGY: none         # no git checkout needed
  script:
    - echo "Using artifact from build job..."
    - ls dist/                 # artifact already downloaded
    - ./deploy.sh

# Related: control submodule fetching
variables:
  GIT_SUBMODULE_STRATEGY: normal  # clone/fetch submodules too

# Protected variables are set in:
# Settings > CI/CD > Variables > Add variable
# Tick "Protected variable" checkbox

# A protected variable is ONLY available in jobs running on:
# 1. Protected branches (e.g. main, production)
# 2. Protected tags

# Example: PROD_API_KEY is protected:
deploy-production:
  stage: deploy
  script:
    - echo "Using: $PROD_API_KEY"    # only available because main is protected
  rules:
    - if: $CI_COMMIT_BRANCH == "main"  # main is a protected branch

# feature branches (unprotected) CANNOT access $PROD_API_KEY:
test-on-feature:
  script:
    - echo "$PROD_API_KEY"   # will be empty - variable not available here
  rules:
    - if: $CI_COMMIT_BRANCH =~ /^feature/

# Protected branches in GitLab:
# Settings > Repository > Protected branches
# Can restrict push access to Maintainers, Developers, No one
# Can require merge request approval before merging
# Can require status checks (pipeline must pass)

# Debugging tips:

# 1. Check the full job log - error is usually at the bottom
# Build > Pipelines > Click the failed job > View log

# 2. Add debug output to the script:
job-debug:
  script:
    - env                        # print all environment variables
    - ls -la                     # show workspace contents
    - which node && node -v      # verify tools are installed
    - cat /etc/os-release        # check OS in the Docker image

# 3. Enable CI/CD debug logging:
variables:
  CI_DEBUG_TRACE: "true"         # very verbose - shows all shell commands

# 4. Re-run a single failed job:
# Click the failed job > Retry
# Or retry from the pipeline view

# 5. Use CI Lint to validate YAML before pushing:
# Build > Pipelines > CI Lint