GitLab CI/CD: Repository Location, Predefined Variables, Tool Images, and Common Configuration Questions

Introduction

When you start building DevSecOps pipelines in GitLab, you quickly encounter questions about where code lives, which environment variables you can rely on, and how to choose the right Docker image for security tools such as npm audit or Retire.js. This article consolidates the most frequently asked questions from the GitLab CI/CD labs and provides clear, actionable answers. By the end of the guide you will know:

• Where the repository is cloned during a pipeline run.
• Which predefined variables are available out‑of‑the‑box.
• How to pick an optimal Docker image for Node‑based security scans.
• Why Retire.js may still report low/medium findings when you limit severity.
• How to safely run InSpec compliance checks against a production server from a CI/CD job.

1. Where Does the Repository Reside During a Pipeline?

1.1 The Source Repository

• GitLab hosts the canonical source code repository. All branches, tags, and merge requests live here.

1.2 The Runner’s Workspace

• When a pipeline is triggered, GitLab Runner automatically clones the repository into a temporary working directory on the runner machine.
• Because the code is already present, you do not need to add an explicit git clone step in your .gitlab-ci.yml.
• After the job finishes, the runner discards the workspace, ensuring a clean environment for the next job.

Tip: If you need to keep a copy of the repository for debugging, enable the artifacts keyword to archive the workspace after the job completes.

2. Predefined CI/CD Variables in GitLab

GitLab injects a rich set of environment variables into every job. They are read‑only and can be referenced directly in your scripts or YAML configuration.

Note: A full list of predefined variables is available in the official GitLab docs under CI/CD predefined variables.

3. Choosing the Right Docker Image for NPM Audit

3.1 Why the Image Matters

Security tools need the same runtime as your application to produce accurate results. Selecting an image that mirrors your production environment reduces false positives and eliminates version mismatches.

3.2 Recommended Base Image

image: node:18   # Replace 18 with the exact major version you use

• node:<major> – Guarantees the Node.js version matches the one declared in your package.json.
• node:latest – Useful for quick prototypes but can introduce breaking changes when the upstream image updates.

3.3 Extending the Image (Optional)

If you need additional tools (e.g., jq, curl), create a custom image:

FROM node:18
RUN apt-get update && apt-get install -y jq curl

Then reference it in the pipeline:

image: registry.example.com/custom-node-audit:latest

3.4 Sample NPM Audit Job

npm_audit:
  stage: test
  script:
    - npm ci          # Install exact dependencies
    - npm audit --json > audit-report.json
    - cat audit-report.json | jq .
  artifacts:
    paths:
      - audit-report.json

4. Why Retire.js Still Shows Low & Medium Findings When Using --severity high

• Retire.js evaluates vulnerabilities based on its internal database. The --severity flag only influences the exit code (i.e., whether the job fails) – it does not filter the output.
• Consequently, the console will still list every finding, but the job will exit with a non‑zero status only if a vulnerability meets the specified severity threshold.

How to Suppress Lower‑Severity Output

retire --severity high --output json | jq 'select(.severity=="high")'

Or use the --ignore option to exclude specific severity levels.

5. Running InSpec Compliance Checks Against Production

5.1 What Happens When You Store a Private SSH Key in CI/CD

1. The private key is added to the runner’s protected variables (e.g., PROD_SSH_KEY).
2. During the job, the key is written to a temporary file and used to open an SSH session to the target host.

5.2 The Role of DEPLOYMENT_SERVER

• The variable DEPLOYMENT_SERVER holds the hostname or IP address of the production machine you want to test.
• The InSpec command typically looks like:

inspec_test:
  stage: compliance
  script:
    - echo "$PROD_SSH_KEY" > /tmp/id_rsa
    - chmod 600 /tmp/id_rsa
    - inspec exec controls/ --target ssh://$DEPLOYMENT_SERVER --key-files /tmp/id_rsa

5.3 Security Best Practices

Common Questions & Tips

Q1: Do I need to git clone inside a job?

A: No. GitLab Runner automatically clones the repository into the job’s workspace.

Q2: Can I override a predefined variable?

A: Yes, but only within the scope of a job using the variables: keyword. Overriding a predefined variable may lead to unexpected behavior, so use it sparingly.

Q3: How do I debug a failing pipeline that uses a custom Docker image?

A: Add a script: step with env and cat /etc/os-release to inspect the environment, or use the docker run -it command locally to reproduce the container.

Q4: What if my pipeline needs both Node.js and Python?

A: Create a multi‑stage image that installs both runtimes, or use separate jobs with different images and share artifacts between them.

Conclusion

Understanding where your code lives, leveraging GitLab’s predefined variables, and selecting the right Docker image are foundational steps for building reliable DevSecOps pipelines. By following the guidelines above, you can integrate tools like npm audit, Retire.js, and InSpec with confidence, while maintaining security best practices for production testing. Happy automating!