08 · Continuous deliveryLab 45 / 59

Guided labjenkins

Jenkins Pipeline: Build, Scan and Push an Image

Take a commit to a scanned, tagged image in a registry, with a gate that blocks rather than reports.

Time: 55 min
Level: Intermediate
Objectives: 4 objectives
Cost: Free

Start the lab Challenge

Where this fits in the platform

Already built

This lab adds

A commit that becomes a tagged image in the registry

Which lets you

Enterprise Multibranch CI/CD Pipeline with SonarQube & Trivy

Before you start

You will need

Docker
Jenkins with the Docker Pipeline plugin
A registry account

You do not need these already — the lab environment below provides them.

You will be able to

Build a container image from a pipeline without leaking credentials
Fail a build on a vulnerability rather than logging one
Tag images so a deployment can be traced to a commit

Cost — Free

— local Jenkins and a free registry account.

Nothing to pay in the browser. Open the terminal runs this against a simulated cloud — the same API calls and the same commands, with no account and no bill. The figure above applies only if you build it in your own.

How to clean up →

The scenario#

The pipeline builds an image and pushes it as latest. Nobody can say which commit is in production, the scan runs after the push, and the registry password is an environment variable in the job configuration.

Hands-on environment

Run this lab in a real terminal, free and in your browser. The environment is temporary and yours alone — break it as much as you like.

Open the terminal

Opens in Killercoda, in a new tab — keep this page open for the steps.

Run it on your own machine

Run this lab on your own machine. One command starts the environment, with everything the lab needs already installed:

You will need:

docker

git clone https://github.com/EgyKode/EgyKode-lab.git
cd EgyKode-lab
./egykode start cicd
./egykode shell

You need Docker and Git installed. Everything else runs inside the environment. The first start downloads it and takes a few minutes; later starts are seconds.

Not sure what you already have? Run: npm run doctor — it checks and changes nothing.

Anything you tick here is your own record. EgyKode cannot see inside that terminal, so the success criteria stay self-assessed even when the environment checks your work for you.

The pipeline

Step 1 of 4

What you are proving: You can produce an image tagged with the commit that built it

Marking this settles success criterion 1.

groovy

pipeline {
  agent any
 
  environment {
    REGISTRY   = 'docker.io/waleeddarwesh'
    IMAGE      = 'egykode-demo'
    // Short SHA: traceable, immutable, and sortable by build.
    TAG        = "${env.GIT_COMMIT.take(7)}"
  }
 
  options {
    timeout(time: 20, unit: 'MINUTES')
    disableConcurrentBuilds()
    buildDiscarder(logRotator(numToKeepStr: '20'))
  }
 
  stages {
    stage('Checkout') {
      steps { checkout scm }
    }
 
    stage('Unit tests') {
      steps { sh 'make test || echo "no tests yet"' }
    }
 
    stage('Build image') {
      steps {
        sh 'docker build -t $REGISTRY/$IMAGE:$TAG .'
      }
    }
 
    stage('Scan image') {
      steps {
        // --exit-code 1 is what turns a report into a gate.
        sh '''
          docker run --rm \
            -v /var/run/docker.sock:/var/run/docker.sock \
            aquasec/trivy:latest image \
            --exit-code 1 --severity HIGH,CRITICAL --ignore-unfixed \
            $REGISTRY/$IMAGE:$TAG
        '''
      }
    }
 
    stage('Push') {
      when { branch 'main' }
      steps {
        withCredentials([usernamePassword(
          credentialsId: 'registry',
          usernameVariable: 'REG_USER',
          passwordVariable: 'REG_PASS')]) {
          sh '''
            echo "$REG_PASS" | docker login $REGISTRY -u "$REG_USER" --password-stdin
            docker push $REGISTRY/$IMAGE:$TAG
            docker logout $REGISTRY
          '''
        }
      }
    }
  }
 
  post {
    always { sh 'docker image prune -f || true' }
  }
}

What you are proving: You can prove the vulnerability gate stops a build, using an image you know is old

Marking this settles success criterion 2.

Use a frozen point release of a supported distribution, not an end-of-life one:

dockerfile

FROM debian:12.5-slim   # a snapshot Debian has since shipped fixes for
RUN apt-get update && apt-get install -y curl

Run the pipeline. The scan stage should fail and the push stage should never execute. A gate you have not seen fail is a gate you cannot trust — this is the only way to know it is wired up.

Then fix it, by moving to the tag that still rebuilds:

dockerfile

FROM debian:12-slim
RUN apt-get update && apt-get install -y --no-install-recommends curl \
    && rm -rf /var/lib/apt/lists/*

Measured today: debian:12.5-slim reports 15 distinct HIGH or CRITICAL findings and exits 1; debian:12-slim reports 0 and exits 0. Same distribution, same package set — the only difference is that one tag is a snapshot nobody rebuilds and the other is rebuilt as fixes land.

That is the lesson underneath the exercise. A base image is a frozen point in time. Nothing about it improves on its own, and the gap between it and the fixes that exist only widens. docker build --pull is not housekeeping.

Clean up#

Run this even if you did not finish.

Terminal

docker image prune -af
docker logout docker.io

Cost of this lab: Free — local Jenkins and a free registry account.

Maintained by others, on Killercoda. Useful for extra repetition on one tool — it does not complete this lab or settle any criterion above.

Trivy scenariosmore on image scanning

Success criteria

0 of 4

The concept behind it

Continuous Integration (Jenkins)

Ready to try it without help?Do the challenge

Next up

Lab 45 of 59 on the project path

Enterprise Multibranch CI/CD Pipeline with SonarQube & TrivyMake a commit build, get scanned for code and image vulnerabilities, and deploy itself — with gates that block.Why next: A commit that becomes a tagged image in the registry31 minAdvanced

Previous: Jenkins Fundamentals & Role-Based Access